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Alles zur Programmierung des Amiga. 
Themen dieser Ausgabe sind z.B.: 
Compiler-Bau 
3-D-Effekte 

Besonderheiten unter OS 2.1 und 3.0 
Objektorientierte Programmierung 
Strategiespiel-Algorithmen 
und viele Tips & Tricks, für alle, die 
programmieren oder es lernen wollen 


Von Amiga-Experten geschrieben. 
Mitwirkende Autoren u.a 
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■ Rudolf und Ilse Wolf 
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Seit mehr als 5 Jahren bieten wir Software für den Commodore 
Amiga an. In dieser Zeit haben wir über 150 kommerzielle 
Software-Produkte mit großem Erfolg veröffentlicht. Die Marken¬ 
bezeichnung Schatztruhe haben wir zu einem Synonym für qualitativ 
hochwertige deutsche Produkte geprägt und Ihr Programm könnte 
bereits unser nächster Bestseller werden. Vertrauen Sie auf unser 
Know-How, und lassen Sie uns eine aktive Partnerschaft beginnen. 

Wir suchen für die Computer der Commodore-Amiga-Familie 
ständig neu entwickelte Software für den kommerziellen Vertrieb: 
z.B. Büroanwendungen, Spiele, Grafiksoftware, DFÜ, DTP, Musik, 
kleinere Tools oder umfangreiche Projektentwicklungen. 

Durch unsere regelmäßig erscheinenden Publikationen im Magazin¬ 
bereich sowie durch die professionelle Schatztruhe-Serie in Verbin¬ 
dung mit einer optimalen Distributionspolitik, verfügen wir über die 
besten Voraussetzungen, Ihr Produkt bestmöglich zu vermarkten. 

Wir bieten Ihnen Top-Konditionen, sowohl Festpreise als auch 
verkaufsabhängige Provisionen, und legen großen Wert auf eine 
intensive Zusammenarbeit mit ambitionierten Programmierern. 
Senden Sie uns eine Voll- oder Demoversion Ihrer Software ein. Herr 
Montenevoso. der Leiter unserer Abteilung für Projektplanung und 
Betreuung, wird sich kurzfristig mit Ihnen in Verbindung setzen. 

Fordern Sie außerdem kostenlos und unverbindlich unseren 
"Leitfaden für Programmierer" an, der Sie ausführlich über alle 
Aspekte des Vertriebes, Verdienstmöglichkeiten, Vertriebskonzepte 
u.ä. informiert. 

Lassen Sie das Kapital in Ihrer Diskettenbox nicht verfallen. Senden 
Sie uns noch heute Ihre Software. Auch Hobby-Programmierer haben 
gute Chancen! 

Wir freuen uns darauf, Ihre Software zu vermarkten! Setzen Sie sich 
also noch heute mit uns in Verbindung! 
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Stefan Ossowski's Schatztruhe Gesellschaft für Software mbH, Veronikastraße 33,4300 Essen 1, Tel.: 0201 / 798447 














































































INHALTSVERZEICHNIS 



D ieses Sonderheft der AMIGA-Magazin-Redaktion dreht 
sich ausschließlich ums Programmieren, und da ist 
bestimmt auch was für Sie dabei. Wir stellen ausführ¬ 
lich wichtige Programmiersprachen für den Amiga vor, richten 
uns mit Artikeln sowohl an Einsteiger als auch Profis. Unsere 
Autoren liefern Ihnen qualitativ hochwertige Informationen: 
Fridtjof Siebert (Entwickler von Oberon), Peter Wollschlaeger, 
Jens Gelhar (Vater des C++-Compilers), Thomas Pfrengle und 
Ulrich Sigmund (Cluster), Dietmar Heidrich (Entwickler des 
OMA-Assembler) u.a. 

Für Programmierer ist der Amiga eine fantastische Spiel¬ 
wiese. Das belegt Monat für Monat das rege Interesse an den 
entsprechenden Rubriken des AMIGA-Magazins - auch ein 
Blick in den PD-Pool spricht Bände. Kein Wunder werden Sie 
sagen, verfügt der Amiga doch über ein Betriebssystem, das 
sich mit dem von Unix messen kann. Was Amiga-Program- 
mierem schon in Fleisch und Blut übergegangen ist, bereitet 
den kommerziellen MS-DOS-Entwicklern Magengeschwüre: 
der Umstieg auf Windows. Die Umstellung auf Multitasking 
scheint größere Probleme zu bereiten als befürchtet. Uns, die 
es nicht anders kennen, bleibt das oftmals unverständlich. 
Grund genug, sich mit den Unterschieden der Windows- und 
Amiga-Programmierung auseinanderzusetzen. Unser Bericht 
»Amiga vs. Windows« verdeutlicht im Detail, welche Unge¬ 
reimtheiten bei der Programm-Umsetzung vom Amiga auf 
Windows auftreten. 

Besonders gespannt sind wir auf die Resonanz zu unserem 
Programmierwettbewerb (Seite 6). Ob er sich durchführen 
läßt, liegt einzig und allein an Ihnen - den Amiga-Program- 
mierern und Ihrem Know-how. 

Viel Spaß mit der ersten Ausgabe von »Faszination Pro¬ 
grammieren« wünschen aus Ihrem AMIGA-Team: 
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Wer steht hinter der ersten Aus¬ 
gabe des AMIGA-Magazin-Son- 
derhefts »Faszination Program¬ 
mieren«? Natürlich eine ganze 
Menge Programmierer, die sich 
privat oder beruflich der Pro¬ 
grammierung und speziell dem 
Amiga verschrieben haben. 

von Ulrich Brieden 

D amit Sie die Leute auch einmal ken- 
nenlemen, die an diesem Heft mitge¬ 
wirkt haben, stellen wir Ihnen hier alle 
Autoren kurz vor. 

Wie Sie selbst sehen, haben viele bekannte 
und berühmte Programmierer an diesem Son¬ 
derheft mitgewirkt. Experten wie Fridtjof 
Siebert, der Oberon-2 für den Amiga ent¬ 
wickelte, oder Peter Wollschlaeger, bekann¬ 
ter Autor diverser Fachbücher zum Amiga, 
waren genauso bereit mitzumachen, wie 
Edgar Meyzis, langjähriger Autor von Fach¬ 
artikeln für das AMIGA-Magazin oder Ilse 
und Rudolf Wolf (in Österreich bekannt als 
die »Computerwölfe«). 

Aber nicht nur die alten Hasen haben mit¬ 
gemacht - auch die »Profis von Morgen« 
mischten mit. Am besten Sie schauen sich 
einfach mal an, wer alles dabei ist. 

Und wenn Sie bei der nächsten Ausgabe 
mit anpacken möchten, schreiben Sie uns 
Ihre Vorschläge. Schicken Sie Ihre Beiträge 
einfach an unsere Redaktion: 
AMIGA-Magazin 

Kennwort: Faszination Programmieren 
Markt & Technik Verlag AG 
Hans-Pinsel-Str. 2 

8013 Haar bei München ■ 


Fridtjof Siebert: Wer 
kennt ihn nicht. Er ist der 
Entwickler von Oberon-2 
für den Amiga. 1971 hat 
man ihn »auf diese Welt 
losgelassen«. Im dreizehn¬ 
ten Lebensjahr bekam er 
einen C 64, wechselte dann 
zum Amiga 500. Seit 1990 
entwickelt er Oberon. Ne¬ 
benbei studiert er Informa¬ 
tik an der Stuttgarter Uni, 
nachdem er seinen Zivil¬ 
dienst ableistete. 


Dietmar Heidrich 

Erste Computerschritte 
erlernte der jetzt 24jährige 
1991 auf einem Apple II. 
Auch die Ära des VC-20 
erlebte er mit. 1984 hatte 
er den ersten eigenen 
Computer, einen C 64 mit 
Floppy. Er programmierte 
kleinere Programme, dar¬ 
unter ein Disk-Checker 
und ein Kopierprogramm 
fürs DolphinDOS sowie den Debugger »Debug64«. 
1986 lernte er den Amiga kennen und entwickelt seit 
1988 den optimierenden Amiga-Makro-Assembler 
»OMA«. Seit Oktober 1989 studiert er Informatik an 
der Technischen Universität Karlsruhe. 


Christof ßrühann 

Der 20jährige kam wie viele 
andere auch über den C 64 
zum Amiga. Der Abiturient 
leistet z.Zt. seinen Zivildienst 
ab und wird noch in diesem 
Jahr sein Informatikstudium 
beginnen. Seinen Amiga 
nutzt er vorwiegend zum Pro¬ 
grammieren in C und Assem¬ 
bler. 


Edgar Meyzis 
Den AMIGA-Magazin- 
Lesem ist er durch seine 
fantastischen Program¬ 
mierkurse ein Begriff. Er 
studierte E-Technik, 
Wirtschaftswissenschaf¬ 
ten und Informatik und 
ist z.Zt. als Berater nach 
mehrjähriger Leitung 
eines Ingenieurbüros tä¬ 
tig. Er programmiert den 
Amiga gerne wegen sei¬ 
nes modernen Betriebs¬ 
systems, das Experimente zuläßt, deren Ergebnisse auf 
größere Systeme übertragbar ist. 





Astrid Brüggemann 

Dort hinter der Kamera, 
die mich gerade fotogra¬ 
fiert, steht mein Papa. Er 
heißt Bemfried. Wenn 
ich abends schlafe, spielt 
er manchmal mit seinen 
Computern. Am Tag dar¬ 
auf ist er immer ganz 
müde. Er ist sogar schon 
mal mittendrin beim 
Memory spielen auf dem 
Teppich eingeschlafen. Dann habe ich ihm ein Kissen 
unter den Kopf geschoben. So ist mein Papa. 



Bernhard Emese 

Seitdem er den Taschen¬ 
rechner HP-25 besitzt (49 
Programmschritte) und 
darauf »Schiffe versen¬ 
ken« programmierte, hat 
ihn das Thema gefesselt. 
1985 legte er sich einen 
Amiga 1000 zu. Ein 
Urlaub in Südfrankreich, 
der dem Zweck diente, ein ultimatives Compulerspiel 
mit zwei weiteren Programmierern zu entwickeln, 
scheiterte zwar am schönen Wetter, halte aber den¬ 
noch etwas Gutes: seitdem beherrscht er die C-Pro- 
grammierung. Heute führt er zusammen mit einem der 
beiden Programmierer eine Firma für Film- und 
Motion-Control-Software. 





Peter Wollschlaeger 

Er kennt den Amiga in- 
und auswendig. In 
Amiga-Kreisen wurde er 
bekannt durch das »Ami¬ 
ga Assembler-Buch«, das 
»C-Workshop-Buch« 
und dem Buch »Profi- 
Tips und Power-Tricks«. 
Doch auch auf anderen 
Computer-Systemen 
fühlt er sich heimisch - 
Bücher über Windows 
und Macintosh belegen 
es. Er hat mit den verschiedenen grafischen Ober¬ 
flächen keinerlei Probleme: »Wer einmal gelernt hat, 
wie ein GUI (Graphic User Interface) eingesetzt wird, 
kann schnell wechseln. Die Denkweise ist dieselbe, nur 
die Syntax ist neu.« 



Raphael Koch 

Den ersten Kontakt mit 
einem Computer bekam er 
1987. Es war ein C 64. 
Über BASIC kam er zur 
Programmiersprache As¬ 
sembler. 1991 schließlich 
stieg er auf den Amiga um. 
programmierte in Amiga- 
BAS1C, lernte C und 
beherrscht heute MC¬ 
68000-Assembler. 
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Ilse und Rudolf Wolf: 

Den AMIGA-Magazin-Lesem sind beide 
als Österreich-Korrespondenten bekannt. 
Rudolf Wolf kam schon während seines 
Studiums an der TU-Wien mit Computern 
in Kontakt - dem »Mailüfterl«, der heute 
im Wiener Technischen Museum zu 
bewundern ist. Schon damals publizierte 
er erste Artikel in Elektronik-Zeitschriften 
und entwickelte Einplatinen-Computer. In 
seinem Fahrwasser entwickelte sich seine 
Frau Ilse ebenfalls zu einer EDV-Spezia- 
listin und Computer-Journalistin und steht 
heute im Impressum von vier Fachzeit¬ 
schriften. 


Thomas Pfrengle 

Mehr oder weniger dem 
Zufall ist es zu verdanken, 
das sein Interesse am 
Computer weckte. Ein C 
64 war 1984 sein erster 
Computer. Seit 1989 ver¬ 
fügt er über einen Amiga 
und ist neben Ulrich Sig¬ 
mund maßgeblich an der 
Entwicklung der Program¬ 
miersprache »Cluster« beteiligt. Thomas Pfrengle ist 
Informatikstudent in Karlsruhe und arbeitet derzeit fie¬ 
berhaft an einer neuen Cluster-Version. 




Alexander Kochann 

Der 20jährige studiert z.Zt. 
an der Mannheimer Uni¬ 
versität Wirtschaftsinfor¬ 
matik und kann schon jetzt 
auf eine über zehnjährige 
Computererfahrung zu¬ 
rückblicken. Sein erster 
Computer war der Atari 
VCS, dem der C 64 und der 
Amiga folgte. Sein Wissen 
stellt er schon seit einiger 
Zeit den Amiga-Fans als 
freier Autor des AMIGA-Magazins zur Verfügung. 



Oliver Reiff 

Seit geraumer Zeit ist auch 
er als freier Autor für das 
AMIGA-Magazin tätig. Sein 
Start in die Computerwelt 
begann 1987, natürlich mit 
einem Amiga. Er program¬ 
miert leidenschaftlich gern 
MC68000-Assembler. Der 
Noch-Zivildienst-leistende 
wird anschließend ein Infor¬ 
matikstudium in der Karls¬ 
ruher oder Stuttgarter Uni¬ 
versität beginnen. 


Sebastian Wedeniwski 

Sein Steckenpferd ist die 
Grafikprogrammierung in allen 
Varianten. Für die Implemen¬ 
tation verwendet er C und Pas¬ 
cal. sowohl auf dem Amiga als 
auch dem PC. Da er reges In¬ 
teresse an der Mathematik hat, 
ist für ihn auch die Informatik 
von Bedeutung (z.B. Algorith¬ 
menentwicklung. Komplexi¬ 
tätstheorie und formale Spra¬ 
chen). 1991 nahm er am Bundeswettbewerb für Informa¬ 
tik teil; 1992 erreichte er die Endrunde. Glückwunsch. 




Daniel Görtz 
Er begann nicht mit dem 
C 64, sondern dem 
Schneider CPC 464. Die 
weiteren Stationen waren 
schließlich doch der C 
64, dann der Amiga. Er 
bevorzugt die Program¬ 
miersprache C, da in die¬ 
ser Rubrik gute Compiler 
existieren und zudem 
sehr effizienter Code er¬ 
zeugt wird. 


Markus Öllinger 

Erste Computerkenntnisse 
sammelte er mit dem Sinclair 
ZX.81. Bevor er sich endgül¬ 
tig für einen Amiga ent¬ 
schied, lernte er die Assem¬ 
bler-Programmierung auf 
dem C 64. Heute schreibt er 
seine Programme zum größ¬ 
ten Teil in der Programmier¬ 
sprache C, so auch das Pro¬ 
gramm des Monats vom 
AMIGA-Magazin 7/91. Mar¬ 
kus Öllinger studiert Telematik an der Technischen 
Universität Graz. 


Kai Bolay 

1973 erblickte er das Licht der 
Welt und absolvierte am Ende 
seiner schulischen Laufbahn 
sein Abitur, dem der Zivildienst 
folgte. Auch er fing mit dem 
legendären C 64 an. Der Um¬ 
stieg auf den Amiga folgte 
zwangsläufig, der zunächst in 
BASIC und Assembler pro¬ 
grammiert wurde. Vor drei Jahren wechselte Kai Bolay 
zu den Programmiersprachen Modula-2 und Oberon. 





Stefan Herr 

Der jetzt 22jährige studiert 
derzeit im siebten Semester 
Informatik an der Karlsru¬ 
her Universität. Ersten 
Kontakt mit Computern 
hatte er schon 1979 mit 
dem legendären »PET«. 
Seit 1987 entwickelt er 
kommerzielle Software auf 
dem Amiga und ist z.Zt. 
mit der Erstellung der 
EGS-Dokumentation beschäftigt (Extended Graphics 
Standard). 



Georg Herbold 

Sein erster Computer war 
gleich der Amiga, den er 
sich 1987 zulegte. Erste 
Programmiererfahrungen 
sammelte er in Amiga- 
BASIC, stieg aber auf As¬ 
sembler um und speziali¬ 
siert sich seitdem auf die 
Programmierung des Blit- 
ters und schneller Rechen¬ 
operationen. Zur Zeit stu¬ 
diert er Luft- und Raum¬ 
fahrttechnik in Stuttgart. 


Roger Fischlin 

Zuerst waren es Video- 
Spiele, dann der C 64, dem 
schließlich der Amiga folg¬ 
te. Der anfänglichen Spiele¬ 
wut folgte kurze Zeit später 
das Interesse am Program¬ 
mieren. Da sich BASIC als 
zu langsam für die Spiele¬ 
programmierung erwies, 
stieg er noch zu den C 64- 
Zeiten auf Assembler um. 
Dieser Sprache hält er auch heute noch die Treue, 
obwohl er mittlerweile die Vorteile von Hochsprachen 
schätzen lernte. Zur Zeit studiert er Informatik an der 
Frankfurter Universität. 
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WETTBEWERB 



Wir nehmen dieses Sonderheft der 
AMIGA-Magazin-Redaktion für 
Programmierer als Forum und 
rufen zu einem Wettbewerb auf 
der seinesgleichen sucht: Wir 
möchten mit Ihnen ein Program¬ 
mierprojekt durchführen. 

von Rainer Zeitler 

D ie Welt des Amiga verfügt über ein 
gewaltiges Potential exzellenter Pro¬ 
grammierer. Wirft man einen Blick in 
den PD-Pool, merkt man: Gerade in Deutsch¬ 
land schlummern ungeahnte Talente im Ver¬ 
borgenen. Hunderte von namenlosen Einzel- 
kämpfem sind in der Lage, fantastische Utili¬ 
ties zu konstruieren - ein größeres Projekt 
läßt sich alleine allerdings schwer realisieren. 
Genau hier setzen wir an. Wir möchten guten 
Programmierern eine Plattform bieten und 
mit entsprechender Koordination die Appli¬ 
kation entwickeln, die nur so möglich ist. 

Die Idee war schnell geboren, lediglich die 
Umsetzung bereitete Kopfzerbrechen: Wel¬ 
ches Projekt sollten wir in Angriff nehmen? 
Mit welcher Programmiersprache ist es 
durchzuführen? Wer plant und organisiert es? 

Nach einigem Hin und Her entschieden wir 
uns für die Programmiersprache »Oberon- 
2«. Sicher, es gibt andere, ebenso leistungs¬ 
fähige, z.B. »Cluster«, »C« oder »C++«. 
Obwohl C gerade im Amiga-Bereich eine 
beliebte Programmiersprache ist, zeigt sie 
doch gravierende Schwächen - C-Quelltext 
ist nur sehr schwer nachvollziehbar und für 
unser Projekt somit nicht geeignet. Gleiches 
gilt für C++. Blieb also noch Oberon bzw. 
Cluster. Beide bieten leistungsfähige Features 
und jede Sprache hat ihre speziellen Vorzüge. 


Einer davon sprach für Oberon-2: die leichte 
Portierbarkeit auf andere Betriebssysteme. 
Da Cluster eine Amiga-Implementation ist, 
entfällt die Umsetzung und ist somit für 
unser Projekt unzweckmäßig. 

Die Programmiersprache stand also fest, 
doch ein weiteres Problem trat auf: Welche 
Applikation kommt in Frage? In jedem Fall 
muß sie der Bedingung genügen, daß die Pla¬ 
nung auch mit mehreren Programmierern 
durchführbar ist. Drei Vorschläge von uns: 

□ Tabellenkalkulation 

□ Textverarbeitung 

□ Projekt-Management für verschiedene Pro¬ 
grammiersprachen 

Die ersten beiden Alternativen erklären 
sich selbst. Hinter dem Projekt-Management 
verbirgt sich eine für Programmierer hochin¬ 
teressante Idee: Sie soll bei der Kreation 
neuer Programme hilfreich sein: u.a. verwal¬ 
tet sie die verschiedenen Module, beinhaltet 
einen eigenen Editor, unterstützt das Erstel¬ 
len von Flußdiagrammen etc. 

Wie nun können Sie an dem Wettbewerb 
teilnehmen? Zunächst einmal sollten Sie ein 
erfahrener Programmierer sein. Dabei ist es 
völlig unerheblich, ob Sie lediglich eigene 
oder kommerzielle Programme entwerfen. 
Sie sollten hochsprachenerfahren sein, denn 
noch so gute Assemblerkenntnis ist nicht 
gleichbedeutend mit der Beherrschung eines 
Hochsprachen-Compilers wie Oberon-2. Alle 
eingehenden Einsendungen werden von uns 
überprüft, bewertet und ausgewählt. Doch 
auch die Leser, die selbst nicht beim Wettbe¬ 
werb mitmachen möchten, sind aufgerufen, 
ihre bevorzugte Anwendung abzugeben. 

Was gibt's zu gewinnen? Alle Einsendun¬ 
gen, seien es nun Vorschläge zum Projekt 
oder Angebote von Programmierern, die 
gerne Ihren Beitrag zu einem fantastischen 
Programm leisten möchten, kommen in einen 


großen Topf. Die Auslosung wird einen Ge¬ 
winner bestimmen, der ein GVP-Turbo- 
board (MC68030-Prozessor, 25 MHz) für 
den Amiga 2000 nach Hause nehmen darf, 
gestiftet vom offiziellen deutschen Distribu¬ 
tor für GVP-Produkte, der DTM GmbH, 
Dreiherrenstein 6a, 6200 Wiesbaden. Den 
Namen des Gewinners werden wir im näch¬ 
sten »Faszination Programmieren« veröffent¬ 
lichen. Der Rechtsweg ist ausgeschlossen. 

Die Durchführung des Projekts hängt von 
mehreren Faktoren ab. Zunächst müssen min¬ 
destens 20 Programmierer bereit sein, mit¬ 
zuwirken. Die Schweizer Firma A+L AG, 
Däderiz 61, 2540 Grenchen, stellt für alle 
Beteiligten kostenlos die benötigten Oberon- 
2-Systeme zur Verfügung. Stehen die Teil¬ 
nehmer fest, geht's an die Planung, das »Soft¬ 
ware Engineering«. Jeder Programmierer 
erhält genaue Instruktionen. Hierzu wird ein 
Treffen veranstaltet. Die weitere Kommuni¬ 
kation wird via Modem durchgeführt. 

Selbstverständlich ist Enthusiasmus ge¬ 
fragt, denn ein Honorar kann es voraussicht¬ 
lich nicht geben. Dennoch, das Programm 
unterliegt anschließend dem Copyright aller 
Beteiligten und wird der Amiga-Fan- 
Gemeinde zur Verfügung gestellt. 

Selbst Prof. Wirth, Schöpfer der Sprachen 
»Pascal«, »Modula-2« und »Oberon« fand 
Interesse an unserem Projekt. Aus zeitlichen 
Gründen war es ihm aber nicht möglich, das 
Projekt intensiver zu unterstützen. 

Wollen Sie mitmachen? Schicken Sie Ihre 
Vorschläge oder Unterlagen bis zum 
14.2.1993 an: 

AMIGA-Redaktion 

Kennwort: Faszination Programmieren 

Markt & Technik Verlag AG 

Hans-Pinsel-Str. 2, 8013 Haar 

Viel Erfolg wünscht Ihr Amiga-Team. ■ 



Salzdahlumer Straße 196 
D-3300 Braunschweig 
Telefon 0531-63019 
Fax 0531-694448 


Autorisierter Reparatur- 
Service 


C s Commodore 




AMIGA 600 


Umschaltplatine inkl. Kickrom 1.3 
Einbauanleitung 

Ramerweiterung 1MB mit Uhr 
Einbauanleitung 

80 MB Festplatte 
2,5" intern 



AMIGA 500 


MEGI-CHIP. Damit erweitern Sie 
ihren A-500 

auf bis zu 2MB Grafik-Mem. 

Komplett DM 348,- 

Kickstart-Umschaltplatine 

inkl. ROM 1.3 DM 79, 

inkl. ROM 2.0 DM 98, 

Einbauanleitung 


A 500 


DM 98,- 

512KB 

DM 65,- 


A 500 



2 MB 

DM 248,- 

DM 158,- 

A500 + 


DM 839,- 

1MB 
A500 + 

DM129,- 

3 MB 

DM 399,- 


A 500 Netzteil 4,3 A 

DM 85,- 

IC 8372 BIG AGNUS 

1 MB DM 89,- 

IC 8375 BIG AGNUS 

2 MB DM 99,- 


STEREO 

Monitor- 

Boxen 
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Ihre Kompetenz... 



i n V e rbindung mit BBM-Power 


Assembler 

Compiler 

Editor 

Entwicklungs¬ 
umgebung 
Peripherie 
Eigenentwicklungen 
z . B . M a i I b o x 


EUROMAIL 



Händler 


VERSAND UND 
EINZELHANDEL 
Braunschweig 

Helmstedter Str. 1a-3 
Tel. 05 31-2 73 09 11/ 12 
Fax 05 31-2 73 09 20 

EINZELHANDEL 

Berlin 

Giesebrechtsstr. 10 
Tel. 0 30-8 81 80 51 

Bielefeld-Leopoldshöhe 

Hauptstr. 289, 

Tel. 0 52 02-83 4 22 

Hamburg 

Hofweg 46 
Tel.0 40-2 27 31 23 

Magdeburg 

Neustädter Platz 
Tel. 01 71-2 41 02 44 


BESTELLANNAHME 9-12 und 13 - 18 uhr 

Tel. 05 31-2 73 0911/12 
Fax 05 31-2 73 09 20 

Autorisierter _ _■ _ , r _ 

Systemhändler von Vi‘ t-OITimOCIOre 

Fachhändler für Nokia, Hewlett-Packhard, bsc, Nec, Macro 
Systems. Fujitsu, Quantum, EPSON, Star. EIZO, GVP 

Irrtümer und Preisänderungen Vorbehalten. Es gelten 
unsere allgemeinen Geschäftsbedingungen, die wir auf 
Wunsch gern zuschicken. Alle Preise zuzüglich 
Versandkosten. Lieferung per Nachnahme oder 
Vorkassenscheck. Preise und Lieferungen freibleibend. 



GRUNDLAGEN 


Programmieren auf der Workbench 

Geheimnisvolles OS 2.0 


Die Flexibilität der neuen Work¬ 
bench hat Ihren Preis. Konnte 
man unter früheren Kickstart-Ver- 
sionen nur bedingt Änderungen 
an der Workbench vornehmen, 
muß man als Programmierer seit 
OS 2.0 mit den ausgefallensten 
Voreinstellungen rechnen. Wir zei¬ 
gen, was zu beachten ist. 

von Alexander Kochann und Oliver Reiff 

E s war einmal eine blaue Workbench 
mit weißer Schrift, dem fixen Zeichen¬ 
satz Topaz 8 oder 9, einer Auflösung 
von 640 x 256 Pixeln und vier Farben. Und 
damit der Programmierer nicht allzuviel 
Arbeit hatte, gab’s keinerlei Variationen. Man 
traf die Konfiguration auf sämtlichen Amiga- 
Modellen an - lediglich auf den Interlace- 
Modus oder die PAL/NTSC-Auflösung 
mußte man achten. 

Aus und vorbei: Dank der vielfältigen 
Möglichkeiten der neuen Preferences-Pro¬ 
gramme finden sich immer mehr Anwender, 
die ihrer Kreativität freien Lauf lassen und 
ihre Workbench individuell gestalten. Selbst¬ 
verständlich ist das eine tolle Errungenschaft 
des neuen Betriebssystems und nach Kräften 
zu unterstützen. Dennoch - Leidtragende die¬ 


ser Einstellungsvielfalt sind die Programmie¬ 
rer, deren Programme auf alle Eventualitäten 
vorbereitet sein müssen. War es bisher 
unproblematisch, ein Workbench-Fenster zu 
öffnen, sollte man sich jetzt bereits vor dem 
Öffnen alle wichtigen Daten der Workbench 
besorgen. Dazu zählen u.a. der verwendete 
Zeichensatz und dessen Größe, die Bild¬ 
schirmauflösung, die Anzahl der Farben usw. 

Unser Assembler-Listing demonstriert die 
wichtigsten Merkmale, die zu beachten sind: 
Es öffnet ein Fenster auf der Workbench, gibt 
zwei Zeilen Text aus und wartet darauf, daß 
der Benutzer den Menüpunkt »Verlassen« 
auswählt oder einfach das Schließsymbol 
aktiviert. Eigentlich kein Problem - vor 
allem nicht unter OS 2.0 oder höher. 

Schritt für Schritt 

Unsere erste Handlung ist es, das Pro¬ 
gramm beim Nichtvorhandensein des neuen 
Betriebssystems abzubrechen. Wir verglei¬ 
chen dabei die Version der Exec-Library mit 
der Zahl 37. Diese ist gleichbedeutend mit 
der von Commodore ausgelieferten Kickstart 
2.04. Zwar geistern hier und da noch V36- 
Versionen umher - dabei handelt es sich aber 
um ehemalige Beta-Versionen: sie sollten 
nicht berücksichtigt werden. 

Ab jetzt gilt's. Zunächst ist die Adresse des 
Workbench-Screens in Erfahrung zu bringen. 
Über diesen Screen-Zeiger läßt sich allerhand 
Interessantes in Erfahrung bringen; doch 


dazu später mehr. Die Intuition-Library 
(ebenfalls V37) stellt hierfür die Funktion 
LockPubScreenO zur Verfügung. Diese rufen 
wir einfach mit dem Parameter »Workbench« 
auf. Gegenüber der schon bekannten Open- 
Workbench()-Funktion besitzt sie einen ent¬ 
scheidenden Vorteil: Der Screen (in unserem 
Fall ist das der Workbench-Schirm) läßt sich 
nicht mehr schließen, es sei denn, wir benut¬ 
zen UnlockPubScreen(). Dieser Befehl teilt 
dem Betriebssystem bzw. dem Programm, 
das den Schirm öffnete, mit, daß wir ihn 
nicht mehr benötigen. Tätigen wir den Aufruf 
nicht, ist es bis zum Neustart nicht mehr 
möglich, den Schirm zu schließen. Also nicht 
vergessen! 

Bevor wir unser Fenster mit OpenWin- 
dow() öffnen, benötigen wir noch das eine 
oder andere Datum, z.B. die Breite und Höhe 
der Workbench. Da ein Fenster aber bekannt¬ 
lich (bis auf eine Ausnahme) mitsamt Rah¬ 
men dargestellt wird, sind eigentlich die Rah¬ 
menkoordinaten interessant, denn die Höhe 
der Titelleiste ist variabel - eine einfache 
Zeichensatzänderung kann das bewirken. 

Zum Glück spendiert uns das Betriebssy¬ 
stem die Tags »WA_InnerWidth« (TAG_ 
USER+118) und »WA_InnerHeight« 
(TAG_USER+119). Mit diesen kann man die 
Höhe und Breite des Fensters ohne den Rah¬ 
men angeben, dessen Breite und Höhe das 
Betriebssystem dann für uns addiert (nicht zu 
verwechseln mit dem Window-Flag »Gim- 
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meZeroZero«). Dadurch wird das gesamte 
Fenster natürlich größer und ob es dann noch 
auf die Workbench paßt, hängt eben von 
deren Größe ab, die sehr stark variieren kann. 
Wir brauchen jetzt aber nicht umständlich die 
Höhe und Breite des Screens und des Fen¬ 
sters zu vergleichen. Es gibt in der Regel nur 
zwei Möglichkeiten, die einen Programmie¬ 
rer interessieren: 

1. Das Fenster muß unbedingt in der ange¬ 
gebenen Größe geöffnet werden. Ist dies 
nicht möglich, bekommt man von OpenWin- 
dowTagList() eben eine Fehlermeldung 
(NULL) zurück. Jetzt sollte man den Benut¬ 
zer mit einem Requester darauf aufmerksam 
machen, daß der Screen zu klein oder das 
Fenster zu groß ist. 

2. Die Größe des Fensters kann im Notfall 
korrigiert werden. Dazu gibt man beim Auf¬ 
ruf noch den Tag »WA_AutoAdjust« 
(TAG_USER+144) an. Jetzt wird das Fenster 
so verschoben und verkleinert, daß es immer 
auf den Screen paßt. Diese Möglichkeit nut¬ 
zen wir in unserem Beispielprogamm. 

Jetzt möchten wir zwei Zeilen Text ausge¬ 
ben. Dazu benötigen wir wichtige Informa¬ 
tionen, und zwar z.B. die Höhe des einge¬ 
stellten Zeichensatzes (Font). Wir bedienen 
uns hierzu der Funktion GetScreenDraw- 
Info(), die uns die Adresse des Zeichensatzes 
und andere wichtige Daten zur Verfügung 
stellt, die wir später noch benötigen. Im Ele¬ 
ment »dri_Font« (Offset 8) finden wir den 
Zeiger auf den voreingestellten Screen-Font. 
Das Element »tf_YSize« (Offset 20) enthält 
den von uns gesuchten Wert: die maximale 
Höhe des Zeichensatzes. Damit der Text 
nicht zu nahe am Rahmen plaziert wird, 
addieren wir jeweils vier Pixel Abstand oben 
und unten dazu. 

Da wir die Fensterbreite der des Texts 
anpassen möchten, müssen wir also zunächst 


die erforderliche Textbreite in Erfahrung 
bringen. Hier hilft uns die Funktion »Text- 
LengthO« der Graphics-Library weiter. Die 
Funktion verlangt u.a. als Argument den Zei¬ 
ger auf den RastPort unseres Fensters. Da wir 
den eingestellten Font benutzen, reicht es 
aus, den in der Screen-Struktur vorhandenen 
zu nehmen (»sc_RastPort«, Offset 84). Zur 
Breite addieren wir wiederum vier Pixel links 
und rechts. 

Nun sollten wir uns die Position des Fen¬ 
sters überlegen. Viele Programme öffnen ihr 
Fenster direkt unter der Screen-Leiste. Deren 
Höhe finden wir in der Screen-Struktur im 
Element »scJBarHeight« (Offset 30). Wir 
addieren einen Pixel und erhalten so die 
obere Position; die linke setzen wir auf Null. 

Nachdem wir nun die wichtigsten Daten in 
Erfahrung gebracht haben, öffnen wir das 
Fenster mit der Funktion »OpenWindowTag- 
List()«. Tritt ein Fehler auf, ist der Screen zu 
klein. Ist alles in Ordnung, läßt sich das 
erforderliche Menü erstellen und einbinden. 

Auch hier kennt das Betriebssystem OS 2.0 
leistungsfähige Routinen, die uns die meiste 
Arbeit abnehmen: wir finden sie in der Gad- 
tools-Library. Zuerst müssen wir die Funk¬ 
tion CreateMenusA() mit der eigenen New- 
Menu-Struktur und einer optionalen TagList 
aufrufen. Das so erhaltene Menügerüst ist 
noch mit den Positionsdaten zu füllen. Das 
übernimmt die Funktion LayoutMenusA(), 
die allerdings noch einen sog. Zeiger auf eine 
Visuallnfo-Struktur erwartet. Diesen erhalten 
wir durch Aufruf von GetVisualInfoA(). Ist 
auch das fehlerfrei geschehen, läßt sich die 
Menü-Struktur via SetMenuStripO anfügen. 
Unabhängig vom eingestellten Zeichensatz 
stellt das Betriebssystem das Menü immer 
korrekt dar. 

Zum Text: Den ersten möchten wir in Fett¬ 
schrift ausgeben, den zweiten ohne jegliche 


Attribute. Nun darf man in keinem Fall 
davon ausgehen, daß Farbe 1 die Schrift- und 
Farbe 0 die Hintergrundfarbe ist - ab OS 3.0 
läßt sich auch das vom Benutzer variabel ein¬ 
stellen. Welche Farbe welche Funktion 
erfüllt, erfahren wir aus der PenArray-Struk- 
tur. Das dri_Pens-Element (Offset 4) der 
Drawlnfo-Struktur gibt darüber Auskunft. 

Somit kennen wir jetzt auch die Textfar¬ 
ben. Was uns nun noch fehlt, ist die Textpo¬ 
sition. Wir öffnen bewußt kein GimmeZero- 
Zero-Fenster, da es wesentlich mehr Speicher 
benötigt und zudem extrem träge ist. Wir 
müssen uns demzufolge zunächst die Breite 
des linken und oberen Fensterrahmens besor¬ 
gen: in den Elementen wd_BorderLeft (Off¬ 
set 54) und wd_BorderTop (Offset 55) der 
Fensterstruktur. Vergessen dürfen wir nicht 
die vier Pixel Abstand vom Rahmen. Addie¬ 
ren müssen wir außerdem den Wert der 
Grundlinie des Zeichensatzes: aus dem Ele¬ 
ment tf_BaseLine (Offset 26) der Font-Struk¬ 
tur. Der Text kann ausgegeben werden. 

Fertig? Nicht ganz. Nachdem wir die 
Nachricht (Message) zum Beenden erhalten 
haben, ist unbedingt alles freizugeben, was 
zuvor reserviert wurde: Die Menü-Struktur 
mit FreeMenus(), die Visuallnfo-Struktur mit 
FreeVisuallnfoQ, FreeDrawInfo() und Un- 
lockPupScreen(). Schießlich ist noch das 
Fenster zu schließen, auch die Libraries dür¬ 
fen wir nicht vergessen. 

Das Beispielprogramm zeigt einen Teil der 
Probleme auf und demonstriert, was unter OS 
2.0 und höher u.a. zu beachten zu ist - aber 
eben nur einen Teil. Wer sicherstellen 
möchte, daß seine Programme kompatibel 
sind, sollte sich an die auf Seite 87 vorge¬ 
stellten Grundregeln halten. rz 

Literaturhinweise: 

[ 1 ] Zeitler. Rainer: »Was lange währt...« - Programmieren unter OS 
2.0, AMIGA-Magazin 1-8/92, Markt & Technik Verlag AG 
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0 M.h, 2.0 

Das umfangreiche Makro-Assembler-Paket für alle Amiga Computer 



Amiga-test 


Hier ist Ihr leistungsfähiges und 
schnelles Makro-Assemblerpaket. 
Für hochoptimierte Codes der 
Motorola-68000-Familie. Mit 
allem, was dazu gehört: 

Der Editor hat 20 Textpuffer. 

Da finden Ihre Quellprogramme 
reichlich Platz. 

Der Debu gger öffnet Ihnen per 
Mausklick beliebig viele Fenster. 
Und damit Sie nicht den Durch¬ 
blick verlieren, protokoliert er 
alle ausgeführten Befehle mit. 

Der Linker fügt Ihre Module blitz¬ 
schnell zu fertigen Programmen 
zusammen. 


Weitere Hilfsprogramme, Include- 
files und eine Assembler-Biblio¬ 
thek sorgen für rasantes Tempo 
und komfortable Bedienung. 

Übrigens: O.M.A. 2.0 arbeitet auch 
mit 32-Bit-Prozessoren, Kick¬ 
start 2.0 und ECS. Und wenn Sie Bestell-Nr. 500 85 
große, modularisierte Projekte 
verwalten müssen, rufen Sie ein 
fach das Make-Utilit v auf. 

O.M.A. hat eben wirlich alles, 
was dazu gehört. 


Systemanforderiingen: 

Amiga 500, 1000, 2000, 3000 mit mindestens 
512 Kbyte RAM Kickstart 1.2, 1.3, OS 2.0 


'unvcrbifHllichi' Preisempfebluiig 
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GRUNDLAGEN 


Schnittstellenprogrammierung 

Serielle Machenschaften 


von Bernhard Emese 

M it der Zeit hat der Amiga schon so 
manches Terminalprogramm ver¬ 
kraften dürfen müssen. Doch statt 
zuverlässiger Datenempfänger sind daraus oft 
häßliche lahme und meist sogar noch vergeß¬ 
liche Zeitgenossen geworden, indem sie 
Bytes verschluckten, die jeder andere Rech¬ 
ner noch locker aufgenommen hätte. Der 
Grund dafür ist das serielle Device des 
Amiga-Betriebssystems, das bei hohen Baud¬ 
raten kneift und lieber ab 9 600 Bit/s Augen 
und vor allem Ohren zumacht, wenn es ei¬ 
gentlich gilt, Daten zu empfangen. 

Die Hardware der Custom-Chips unterstüt¬ 
zen die serielle Schnittstelle leidlich, so daß 
beispielsweise die Parity-Prüfung jedes an- 
kommenden Bytes via Software (man be¬ 
achte) Bit für Bit vorzunehmen ist. Kein 
Wunder also, daß die Zeit für hohe Übertra¬ 
gungsraten nicht ausreicht. Zwar entwickelte 
die damalige Commodore-Crew einen »su¬ 
perschnellen« Modus, den RAD_BOOGIE- 
Modus, vorrangig für MIDI-Ansteuerungen 
gedacht. Doch leider versagt auch dieser, 
wenn er 38400 Bit/s zu empfangen hat. 

Damit diese marode Prozedur auf die 
Beine kommt - hier finden Sie das Pro¬ 
gramm »Fastserial.c«. Dabei handelt es sich 
um einen kompletten interruptgesteuerten 
Händler zum Empfang serieller Daten auf 
dem Amiga, der rigoros auf Geschwindigkeit 
getrimmt ist und theoretisch noch mehr als 
38 400 Bit/s empfangen könnte. Hier aller- 


Wollten Sie schon immer wissen, 
wie man die serielle Schnittstelle 
des Amiga effizient ansteuert und 
zusätzlich Übertragungsraten bis 
zu 38400 Bit/s erreicht? Wir zei¬ 
gen, mit welchen Tricks zu arbei¬ 
ten ist und stellen eine funktions¬ 
fähige Implementation vor. 

dings liegt bei der Hardware die Sende- und 
Empfangsgrenze. Es ist durchaus möglich, 
das Programm in ein Terminalprogramm ein¬ 
zubinden und so eine zuverlässige und be¬ 
quem anzusprechende serielle Schnittstelle 
zu haben. 

Anstatt die im Amiga-ROM-Kernel-Refe- 
rence-Manual [ 1 ] beschriebene Prozedur des 
Allokierens von Ports, Extended Serial-IOs 
und OpenDevice-Aufrufen durchzuführen, 
genügt hier ein Aufruf von OpenSer() mit 
entsprechenden Parametern, und schon ist die 
Schnittstelle verfügbar. 

Ein Minimalprogramm, das alle Funktio¬ 
nen des Händlers benutzt, einen Text sendet 
und anschließend einen anderen empfängt, 
zeigt das Listing. Über den IO-Pointer kann 
zusätzlich auch direkt auf die Kontrollstruk¬ 
tur für den seriellen Schnittstellentreiber 
zugegriffen werden. Dieselbe Struktur wird 
vom seriellen Device des Amiga in nahezu 
identischer Weise verwendet. Fastserial be¬ 
nutzt lediglich nicht alle Felder, sondern: 


□ io_Baud: Hier finden wir die aktuelle 
Baudrate 

□ io_RBufLen: Die Größe des Ringpuffers 
in Bytes 

□ io_ReadLen: Anzahl der Datenbits für den 
Empfang 

□ io_WriteLen: Anzahl der Datenbits fürs 
Senden 

□ io_StopBits: Anzahl Stopbits (1 oder 2) 

□ io_SerFlags: Ausgewertet wird nur mit 
SERF_PARTY_ON und SERF_PARTY_ 
ODD 

Die Struktur IOExtSer finden wir in der 
Include-Datei »devices/serial.h«: 

struct IOExtSer { 
struct IOStdReq IOSer; 

UL0NG io.CtlChar; 

UL0NG io.RBufLen; 

ULONG io_ExtFlags; 

UL0NG io.Baud; 

UL0NG io_BrkTime; 

struct IOTArray io_TermArray; 

UBYTE io.ReadLen; 

UBYTE io_WriteLen; 

UBYTE io_StopBitS; 

UBYTE io.SerFlags; 

UW0RD io_Status; 

}; 

Zusätzlich zu den aufgeführten Feldern 
trägt OpenSer() einen Pointer ins Feld IOExt- 
Ser.IOSer.io_Device ein. Der zeigt auf die 
Static-Variable RBFData, in der wir die 
Ringpufferadresse, die Anzahl der darin ent¬ 
haltenen und noch nicht ausgelesenen Bytes 
und die aktuellen In- und Out-Counter finden. 


1: /* 

2: * Amiga-Serial-Interrupt-Treiber für hohe Baudraten. 

3: * Autor: Bernhard Emese 

4: * Geschrieben für Aztec 5.0b ANSI C 5.1992 

5: * Der Treiber ermöglicht Obertragungsraten bis zu 
6: * 38400 Bit/s ohne Handshake. Beim Empfang wird dabei 
7: * allerdings auf die Parity-Prüfung verzichtet, da 

8: * sie per Software durchgeführt werden müßte und zuviel 

9: * Zeit benötigt. Beim Senden wird das Parity-Bit jedoch 

10: * berechnet und gesendet, wenn Parity Enabled ist. 

11: * Compiler-Aufruf für Aztec C 5.0 (16-Bit-Modell) 

12: * cc fastserial.c -ps 

13: * Das Objekt-Modul kann mit C-Programmen zusammengebunden 

14: * werden, um so serielle Daten zu mit hoher Übertragungs- 

15: * rate zu empfangen. 

16: */ 

17: tinclude <exec/types.h> 

18: #include <exec/memory.h> 

19: (finclude <exec/interrupts.h> 

20: #include <functions.h> 

21: Dinclude <hardware/custom.h> 

22: #include <hardware/intbits.h> 

23: Hinclude <devices/serial.h> 

24: 

25: /“* Definitionen “*/ 

26: #define BAUDFAKTOR 3546895L /* Quarz 28.37516 MHz / 8 */ 

27: Idefine SERINTNAME *fastserial.int' 

28: #define OVRUN 0x8000 /* Overrun Bit */ 

29: #define RBF 0x4000 /* Receiver Buffer Full */ 


30: #define TBE 0x2000 /* TRansmitter Buffer empty */ 

31: Sdefine TSRE 0x1000 /* Transmitter Register Empty */ 

32: tdefine RXD 0x0800 

33: #define UARTLONG 0x8000 /*für neuntes Bit, wenn 8 Daten 
34: und Parity gesendet werden soll */ 

35: /* Hardwareregister */ 

36: Hdefine custom (‘((struct Custom *)Oxdff0*00)) 

37: /* Assembler Interrupt Händler als extern deklarieren */ 

38: extern void SerialReceivelnt(); 

39: 

40: /“* Variablen *“/ 

41: /* interne Struktur RBFData, um den interruptgesteuerten 
42: * Rfeceive Ringpuffer zu verwalten */ 

43: static struct SeriallntData { 

44: struct IOExtSer *io; 

4 5: UBYTE *InCount,‘OutCount; 

46: UBYTE ‘Buffer; 

47: SHORT Inhalt; 

48: } RBFData; 

49: 

50: static struct Interrupt *SerInt=NULL,‘Priorinterrupt=NULL; 
51: 

52: /“* Prototypes “*/ 

53: struct IOExtSer ‘OpenSer(ULONG Baud,ULONG BufLen,UBYTE 
54: ReadLen,UBYTE WriteLen,UBYTE Stop,UBYTE Flags); 

55: void ParamSer(struct IOExtSer *io,ULONG Baud,ULONG 

56: BufLen,UBYTE ReadLen,UBYTE WriteLen,UBYTE Stop,UBYTE Flags); 

57: void CloseSer(struct IOExtSer *io); 

58: void WriteSer(register struct IOExtSer *io, 
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GRUNDLAGEN 


Damit ist es dem Hauptprogramm möglich, 
den Puffer beliebig zu manipulieren, z.B. ihn 
zu löschen, indem die Ring-Counter auf die 
Pufferstartadresse gesetzt werden und der 
Inhaltzähler auf 0. Das ist z.B. dann sinnvoll, 
wenn man ein Abbruchzeichen empfängt, das 
alle zuvor gesendeten Daten unwirksam 
macht oder die Baudrate falsch eingestellt 
war und sich Datenmüll im Puffer befindet. 
Das Löschen läßt sich allerdings auch durch 
Auslesen mit ReadSer() ermöglichen, wobei 
letzteres aber wegen des Timeouts und der 
Schleife ein paar Millisekunden länger dau¬ 
ert. Es ist darauf zu achten, daß beim Zugriff 
auf RBFData ein Disable()-Befehl voran 
geht, da ansonsten eventuell eintreffende Zei¬ 
chen verlorengehen, Das Löschen des Ring¬ 
puffers über RBFData muß deshalb so ge¬ 
schehen: 


struct IOExtSer *io; 
struct RBFData *rbf; 

/* io ist durch OpenSerO bereits 
* ordnungsgemäß initialisiert 
*/ 

rbf=(struct RBFData *)io->I0Ser.io.Device; 
/* rbf zeigt auf RBFData */ 

DisableO; 

rbf->InCount=rbf->OutCount=rbf->Buffer; 

/* Zähler auf Anfang des Puffers */ 
rbf->lnhalt=0; 

Enable(); 

Diese Programmversion stellt natürlich nur 
einen Spezialfall dar: Den des schnellen 
Datenempfangs und -sendens. Eine allge¬ 
meingültigere Routine ließe sich jedoch sehr 
einfach erweitern, indem das XON/XOFF- 
Protokoll und eine Semaphore für die exklu¬ 
sive Nutzung verschiedener Tasks hinzuge¬ 


fügt werden. Vermutlich würde sogar ein 
optimal in Assembler programmierter Parity- 
Check, der in der hier besprochenen Routine 
fehlt, gerade noch 38 400 Bit/s beim Emp¬ 
fang ermöglichen. Doch wer braucht schon 
im Zeitalter der Checksummen und aufwen¬ 
digen Protokolle oder gar des selbstredundan¬ 
ten Codes, der sich selbst korrigiert, wenn er 
nur erst einmal, ohne ganze Bytes zu ver¬ 
schlucken, im Puffer angekommen ist, Parity- 
Checks? 

Das Listing ist mit dem Aztec-C-Compiler 
verfaßt. Mit geringen Änderungen ist es auch 
mit anderen C-Compiler zu übersetzen. Das 
Listing finden Sie auch auf der PD-Diskette 
zum Heft (Seite 114). rz 

Literaturhinwei.se: 

[1] Commodore Amiga. AMIGA ROM Kemel Reference Manual 
Devices. Third Edition. Reading 1991 


59 

UBYTE *data,SHORT length) ; 

124 

CloseSer(io); 

60 

SHORT StatSer(register struct IOExtSer *io); 

125 

return(NULL); 

61 

SHORT ReadSer(register struct IOExtSer *io,char *data, 

126 

} 

62 

SHORT length,SHORT Timeout); 

127 


63 

128 

/* 

64 

/*** Funktionen ***/ 

129 

* Verändern der Parameter der seriellen Schnittstelle. Diese 

65 

/* 

130 

* Funktion kann jederzeit aufgerufen werden, um die Baudrate 

66 

* Start der seriellen Kommunikation. Die Schnittstelle wird 

131 

* oder andere Parameter neu zu setzen. Lediglich die Größe 

67 

* mit der gewünschten Baudrate initialisiert (Daten- 

132 

* des Empfangspuffers ist beizubehalten 

68 

* bit-Anzahl, Stoppbit-Anzahl und Parity). Dabei werden 

133 

*/ 

69 

* dieselben Bitdefinitionen für Flags verwendet, die in 

134 

void ParamSer(struct IOExtSer *io,ULONG Baud, 

70 

* devices/serial.h deklariert sind und auch beim Eröffnen 

135 

ULONG BufLen,UBYTE ReadLen,UBYTE WriteLen, 

71 

* des Amiga-Serial-Devices verwendet werden (siehe Amiga ROM 

136 

UBYTE Stop,UBYTE Flags) 

72 

* Kernel Reference Manual, Kapitel 13 Seite 383 ff.). Es 

137 

{ 

73 

* wird ein Empfangspuffer der Größe BufLen angelegt, in den 

138 

USHORT b; 

74 

* später zyklisch serielle Daten eingetragen werden. Die 

139 

io->io_Baud=Baud; 

75 

* Parameter in dieser Funktion repräsentieren alle 

140 

76 

* relevanten Einstellungen. 

141 

b=BAUDFAKTOR/Baud-l ; 

77 

*/ 

142 

if(ReadLen==8 && Flags & SERF_PARTY_ON) bl=0x8000; 

78 

struct IOExtSer * 

143 

custom.serper=b; 

79 

OpenSer(ÜLONG Baud,ULONG BufLen,UBYTE ReadLen, 

144 


80 

UBYTE WriteLen,UBYTE Stop,UBYTE Flags) 

{ 

145 

io->io_RBufLen=BufLen; 

81 

146 

io->io_ReadLen=ReadLen; 

82 

register struct IOExtSer *io; 

147 

io->io_WriteLen=WriteLen; 

83 

UBYTE * SerBu f fer=NULL ; 

148 

io->io_StopBits=Stop; 

84 

LONG error; 

149 

io->io SerFlags=Flags; 

85 


150 

} 

86 

if (! (io=(struct IOExtSer *)AllocMem( 

151 


87 

sizeof(struct IOExtSer) ,MEMF PUBLIC 1 MEMF CLEAR) )) 

152 

/* 

88 

retum(NULL) ; 

153 

* Freigeben der allokierten Daten, Empfangspuffer etc. und 

89 


154 

* Sperren des seriellen Interrupts. CloseSer wird 

90 

ParamSer(io,Baud,BufLen,ReadLen,WriteLen,Stop,Flags); 

155 

* aufgerufen, wenn keine serielle Kommunikation mehr 

91 

156 

* stattfinden soll (meist beim Programmende). 

92 

if(!(Serlnt=(struct Interrupt *) 

157 

*/ 

93 

AllocMem(sizeof(struct Interrupt), 

158 

void CloseSer(struct IOExtSer *io) { 

94 

MEMF_PUBLIC 1 MEMF_CLEAR) )) 

159 

struct SeriallntData *sid; 

95 

goto Fail; 

160 


96 


161 

/* Sperren des Receive Interrupts */ 

97 

if (!( SerBuf fer = (UBYTE* ) AllocMem ( io->io_RBufLen, 

162 

custom.intena=INTF_RBF; 

98 

MEMF_PUBLIC 1 MEMF_CLEAR) )) 

163 


99 

goto Fail; 

164 

/* Wiedereinsetzen des AMIGA Interrupt Händlers V 

100 

165 

if ( Priorinterrupt ) ( 

101 

/* Interrupt Struktur initialisieren, damit Exec bei 

166 

SetlntVector ( INTB.RBF,Priorinterrupt ); 

102 

* Receive-Interrupt zu unserer Routine springt 

167 

PriorInterrupt=NULL; 

103 

* Node-Typ ist Interrupt. Klar */ 

168 

} 

104: 

SerInt->is_Node.ln_Type=NT_INTERRUPT; 

169 


105: 

SerInt->is_Node.ln_Pri=0; 

170 

/* Freigeben der Interrupt-Struktur, der IOExtSer-Struktur 

106 

SerInt->is_Node.ln_Name=SERINTNAME; /* Name für Liste */ 

171 

* und des Empfangspuffers, wenn sie allokiert wurden */ 

107 

/* Dieser Pointer wird dem Händler in Al übergeben */ 

172 

if(Serlnt) { 

108 

SerInt->is_Data= (APTR) fcRBFData; 

173 

FreeMem(Serlnt,sizeof(struct Interrupt)) ; 

109 

SerInt->is_Code=SerialReceiveInt; /* Interrupt-Handler */ 

174 

SerInt=NULL; 

110 

RBFData.InCount=RBFData.OutCount=RBFData.Buffer=SerBuffer; 

175 

} 

111 

/* Ringpuffer auf Anfang, gelöscht */ 

176 

if(io) { 

112 

RBFData.io=io; 

177 

if(RBFData.Buffer) { 

113 

io->IOSer.io_Device=(struct Device *)&RBFData; 

178 

FreeMem(RBFData.Buffer,io->io_RBufLen) ; 

114 


179 

RBFData.Buffer=NULL; 

115 

/* alten Interruptvektor merken, damit nach CloseSer wieder 

180 

) 

116 

* der normale Händler eingesetzt wird */ 

181 

FreeMem(io,sizeof(struct IOExtSer) ); 

117 

PriorInterrupt=SetIntVector(INTB_RBF,SerInt) ; 

182 

io=NULL; 

118 


183 

) 

119 

/* Seriellen Interrupt erlauben, entsprechendes Bit im 

184 

) 

120 

* Interrupt-Enable-Register setzen */ 

185 


121 

custom.intena=INTF_SETCLRIINTF.RBF; 

186 

/* 

122 

return(io) ; 

187 

* Diese Routine wird vom Hauptprogramm zum seriellen Senden 

123 

Fail: 

188 

* einer Anzahl Bytes (z.B. eines Strings) aufgerufen. Die 
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189 

* Anzahl steht in length, *data zeigt auf den auszugebenden 

281 

io->IOSer.io_Data=(APTR)data; 

190 

* String. Beispiel: 

282 

io->IOSer.io_Length=length; 

191 

* WriteSerüo, "Hello WoridMl); 

283 

io->IOSer.io Actual=0; 

192 

* char c='A'; 

284 


193 

* WriteSer(io,&c,l); sendet das Zeichen A 

285 

for(i=0;i<Timeout;i++) { 

194 

* Bei der Ausgabe jedes Byte wird das Parity-Bit per 

286 

/* diese Schleife soll ca. 1 ms dauern */ 

195 

* Software berechnet, da die Amiga-Hardware keine 

287 

if(length==0) 

196 

* Möglichkeit der Parity-Bildung vorsieht. 

288 

break; /* Hauptprogramm will keine Daten */ 

197 

*/ 

289 

if(rbf->Inhalt) { 

198 

void WriteSer(register struct IOExtSer *io, 

290 

*data++=*rbf->OutCount; 

199 

ÜBYTE *data,SHORT length) 

291 

if(++rbf->OutCount>=rbf->Buffer+io->io RBufLen) 

200 

{ 

292 

rbf->OutCount=rbf->Bu f fer; 

201 

register USHORT tx,mask,StopBitMask,ParityBit; 

293 

io->IOSer.io_Actual++; 

202 


294 

length--; 

203 

if(io->io_StopBits==2) 

295 

rbf->Inhalt—; 

204 

StopBitMask=0xQ003; 

296 

} eise { 

205 

eise 

297 

for(j=0;j<100;j++); 

206 

StopBitMask=0x0001; 

298 

} 

207 

StopBitMask«=io->io_WriteLen; 

299 

} 

208 


300 

return(io->IOSer.io Actual); 

209 

if(io->io_SerFlags & SERF_PARTY_ON) { 

301 

} 

210 

StopBitMask«=l; 

302 


211 

ParityBit=l«io->io WriteLen; 

303 

/* 

212 

} 

304 

* Und jetzt die Hauptsache: Schnelle serielle 

213 


305 

* Empfangsroutine in Assembler. Jedes serielle Byte löst den 

214 

/* Alle Bytes nacheinander aussenden. ForbidO verwenden 

306 

* Receive-Interrupt aus, so daß diese Routine angesprungen 

215 

* wir, damit andere Tasks nicht dazwischenfunken und damit 

307 

* wird. Zum besseren Verständnis ist für jede Aktion eine 

216 

* die Stopp-Bitphase durch Taskwechsel nicht verlängert 

308 

* Entsprechung in C als Kommentar hinzugefügt. 

217 

* wird */ 

309 

*/ 

218 

Forbid(); 

310 


219 

while(length--) { 

311 

/* Receive-Puffer-Full-Driver, Interrupt-Routine */ 

220 

tx=*data++; 

312 

221 


313 

#asm 

222 

/* wenn Parity enabled, dann Paritybit berechnen */ 

314 

public _SerialReceiveInt 

223 

if(io->io_SerFlags & SERF_PARTY_ON) { 

315 


224 

for(mask=l«io->io_WriteLen-l;mask!=0;mask»=l) { 

316 

_SerialReceiveInt: 

225 

if(txScmask) tx A =ParityBit; 

317 

;register al struct SeriallntData *rbf; 

226 

} 

318 

;register d4 SHORT rx; 

227 

if(io->io_SerFlags & SERF_PARTY ODD) tx A =ParityBit; 

319 


228 

) 

320 

;rx=custom.serdatr; 

229 


321 

movem.l d4,-(sp) ; d4 auf den Stack retten 

230 

/* Warten, bis der Transmitter-Buffer leer ist, bevor das 

322 

move.w $dff018,d4 ; serielles Byte nach d4 einiesen 

231 

* nächste Byte gesendet wird */ 

323 

232 

while(!(custom.serdatr & TBE)); 

324 

; custom.intreq=INTF_RBF; 

233 


325 

; Receive-Interrupt-Pending-Flag rücksetzen 

234 

/* Interrupt-Pending-Bit für Transmitter (Interrupt wird 

326 

move.w #$0800,$dff09c 

235 

* nicht benötigt) zurücksetzen */ 

327 

move.l (al),a0 ; prüfen, ob im Ringpuffer noch 

236 

custom.intreq=INTFJTBE; 

328 

; Platz ist, sonst Byte verwerfen 

237 


329 

move.l 52(a0),d0 

238 

/* Byte mitsamt Stopp-Bits und Parity ins serielle 

330 

move.w 16(al),dl ;Inhalt >RBufLen ? 

239 

* Datenregister schreiben: Senden läuft */ 

331 

cmp.w d0,dl 

240 

custom.serdat=tx1StopBitMask; 

332 

bcc ..52 

241 

} 

333 


242 

PermitO; 

334 

; *rbf->InCount=rx; 

243 

} 

335 

move.l 4(al),a0 ; Byte in Ringpuffer eintragen 

244 


336 

move.b d4,(aO) 

245 

/* 

337 


246 

* Gibt an, ob und wieviele Byte im Empfangspuffer vorhanden 

338 

; rbf->Inhalt++; 

247 

* sind. Wartet beispielsweise das Hauptprogramm auf 8 Bytes, 

339 

add.w #l,16(al) ; Ringpuffer-Zähler inkrementieren 

248 

* könnte das folgende Sequenz vornehmen: 

340 


249 

* char Daten[8]; 

341 

; if(++rbf->InCount >= rbf->Buffer+rbf->io->io_RBufLen) 

250 

* while(StatSer(io)<8); 

342 

; rbf->InCount=rbf->Buffer; 

251 

* ReadSer(io,&Daten,8,0); 

343 


252 

*/ 

344 

add.l #1,4(al) ; Ringpuffer-InCounter erhöhen 

253 

SHORT StatSer(struct IOExtSer *io) { 

345 

move.l (al),a0 ; wenn Ende des Puffers erreicht, 

254 

register struct SeriallntData * 

346 

; dann InCounter 

255 

rbf=(struct SeriallntData *)(io->IOSer.io_Device); 

347 

move.l 52(a0),d0 ; wieder auf Anfang des Puffers 

256 


348 

add.l 12(al),d0 

257 

return(rbf->Inhalt); 

349 

move.l 4(al),a0 

258 

} 

350 

cmp.l d0,a0 

259 


351 

bcs ..50 

260 

/* 

352 

move.l 12(al) ( 4(al) 

261 

* Liest aus dem Empfangspuffer eine bestimmte Anzahl Bytes 

353 


262 

* nach *data. Wenn weniger Daten im Puffer sind, kehrt die 

354 

; if(rxfcOVRUN) rbf->io->IOSer.io Error=SerErr BufOverFlow; 

263 

* Routine nach Ablauf eines Time-Outs zurück, ansonsten 

355 

..50 

264 

* sofort nach dem Auslesen der Bytes aus dem Receive-Puffer. 

356 

btst.l #15,d4 ; Overrun Error im Empfangsbyte ? 

265 

* Da Time-Out mittels einer Programmschleife realisiert ist, 

357 

beq ..51 

266 

* sollte der Wert bei Amigas mit MC68030-Prozessor 

358 


267 

* entsprechend höher gesetzt werden. Besser ist 

359 

..52 

268 

* selbstverständlich die Nutzung des Timer-Devices, hier 

360 

move.l (al),a0 ; setze entsprechendes Bit in 

269 

* allerdings aufgrund des zur Verfügung stehenden Platzes 

361 

; IOSer->io Error 

270 

* nicht realisierbar. Das hier angegebene Verfahren dient 

362 

move.b #12,31(aO) 

271 

* nur Demonstrationszwecken. Zurückgeliefert wird die 

363 


272 

* tatsächlich gelesene Anzahl Bytes (io->Actual). 

364 

..51 

273 

*/ 

365 

movem.l (sp)+,d4 ; d4 von Stack holen, Empfangsende 

274 

SHORT ReadSer(struct IOExtSer *io,char *data, 

366 

rts 

275 

SHORT length,SHORT Timeout) 

367 


276: 

{ 

368 

#endasm © 1993 M&T 

277: 

register struct SeriallntData * 



278: 

rbf=(struct SeriallntData *)(io->IOSer.io_Device); 



279 

register SHORT i,j,k; 

»Fastserial.c«: Die schnelle Routine läßt sich in schon 

280: 


bestehende Programme problemlos implementieren 
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GRUNDLAGEN 


3-D-Darstellung 

Rot, Grün, 

Jeder hat sie schon bestaunt: Monitore mit animierten 3-D-Darstellun¬ 
gen sind Anziehungspunkte auf jeder Computermesse. Die dritte 
Dimension auf dem Bildschirm hat selbst für Computerprofis noch 
immer den Hauch des Sensationellen. Leider gilt: Je realistischer die 
Darstellung, desto teurer die Hardware. Dabei genügen für den Haus¬ 
gebrauch schon zwei Mark für eine Rot/Grün-Filterbrille, wie man sie 
vom Jahrmarkt aus den 3-D-Kinos kennt. Zusätzlich brauchen Sie noch 
etwas Geschick bei der Belegung der Farbtabelle Ihres Rechners... 



von Bernfried Brüggemann 

Z unächst zu den Grundlagen, wie man 
Objekte per Rot/Grün-Verfahren drei¬ 
dimensional darstellt: Mit unseren bei¬ 
den Augen sehen wir wegen des unterschied¬ 
lichen Blickwinkels leicht voneinander ab¬ 
weichende Bilder unserer Umgebung. Man 
kann sich das schnell verdeutlichen, wenn 
man den Daumen am ausgestreckten Arm 
betrachtet und abwechselnd das rechte und 
linke Auge zukneift. Der Daumen scheint 
vor dem Hintergrund hin- und herzuspringen. 
Der »Daumensprung« wird immer größer, je 
mehr man die Hand dem Gesicht nähert. 


Wenn man mit beiden Augen schaut, 
erzeugt das Gehirn aus den unterschiedlichen 
Bildern den Eindruck der räumlichen Tiefe. 
Man erkennt unmittelbar, in welcher Entfer¬ 
nung sich ein Gegenstand befindet. Das nutzt 
das Rot/Grün-Verfahren für die 3-D-Darstel¬ 
lung aus. Es erzeugt für jedes Auge ein sepa¬ 
rates Bild. Das eine enthält nur grüne, das 
andere nur rote Farben. 

Man kann die beiden Bilder kombinieren 
und beispielsweise auf einem Bildschirm 
überlagern. Damit jedes Auge nur das zu sei¬ 
nem Blickwinkel gehörende Teilbild sieht, 
wird ein Auge mit einem roten, das andere 
mit einem grünen Filter abgedeckt. Da Rot 



Bild 1: Addition ist keine Überlagerung; wenn man wie im Bild unten eine rote 
und grüne Kugel überlagert, müßte die Schnittfläche bei Überlagerung gelb sein 



und Grün 
Komplementär¬ 
farben sind, absor¬ 
biert der Grünfilter den 
Rotanteil des Monitorbilds vollständig, der 
Rotfilter leistet dasselbe für die grüne Farbe. 
Durch eine Rot/Grün-Brille gewinnt der 
Betrachter somit einen räumlichen Eindruck 
der abgebildeten Gegenstände. 


Teuflisches 

Als pragmatischer Programmierer denkt 
man sich: »Rot/Grün-3-D (R/G), das müßte 
doch eigentlich eine der leichtesten Übungen 
für den Farbenzauberer Amiga sein«, und 
geht frisch ans Werk. Um sich nicht mit Vek¬ 
torrechnung und Projektionsgeometrie zu 
plagen, wählt man am besten ein einfaches 
Beispiel und begnügt sich zunächst mit 
Scheibchen, die dank R/G-Verfahren 3-D- 
real vor und hinter dem Bildschirm schweben 
sollen. 

Für das rechte Auge nimmt man den roten 
Filter, für das linke den grünen. Scheibchen, 
die vor dem Bildschirm liegen, erscheinen 
dann in der grünen Ansicht nach rechts ver¬ 
schoben, in der roten nach links. Für Scheib¬ 
chen hinter der Bildschirmebene liegen die 
Verhältnisse genau umgekehrt. Für Scheib¬ 
chen in der Bildschirmebene fallen rote und 
grüne Ansicht zusammen. Jetzt braucht man 
nur noch mit einigen »AreaCircleO«- Anwei¬ 
sungen die Scheiben auf den Bildschirm zu 
bringen. Leider begegnet man an dieser Stelle 
dem Teufel im Detail. Es ist nämlich nicht 
ohne weiteres möglich, einfach rote und 
grüne Ansicht nacheinander auf den Schirm 
zu zeichnen. 

Wenn der Scheibchendurchmesser größer 
ist als der Versatz zwischen den beiden 
Ansichten gibt es einen Rot/Grün-Überlap¬ 
pungsbereich (siehe Bild 1; links). Dieser 
Kembereich muß für beide Augen in der glei¬ 
chen Helligkeit erscheinen wie der Scheib- 
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Bild 2: die 
roten und grü¬ 
nen Scheiben im 
Raum ergeben durch 
eine R-G-Filterbrille 
betrachtet den 3-D- 
Effekt 


chenrest. Wenn die rote Ansicht zuletzt 
gezeichnet wird, ist dieser Kembereich aber 
rot und durch das Grünfilter nicht zu sehen. 
Der Kernbereich müßte gelb gezeichnet wer¬ 
den. Gelb enthält zu gleichen Teilen Rot und 
Grün. Der Kembereich erscheint dann für 
beide Augen in der richtigen Helligkeit und 
fügt sich mit dem roten und grünen Rand zu 
einem runden Scheibchen zusammen. 

Falls mehrere, sich teilweise verdeckende 
Scheibchen unterschiedlicher Helligkeit am 
Bildschirm zu sehen sein sollen, sind eine 
Vielzahl kompliziert geformter Überlap¬ 
pungsflächen mit verschiedensten R/G- 
Mischfarbanteilen darzustellen (Bild 2). Auf 
den ersten Blick scheint dann eine korrekte 
R/G-Überlagerung nur mit großem Aufwand 
möglich zu sein . . . 

Bits mit Maske 

. . . deshalb sollte man noch einen zweiten 
Blick riskieren. Die Tabelle in Bild 4 auf 
Seite 19 gibt eine Übersicht der möglichen 
Farbkombinationen bei vier Helligkeitsstufen 
im R/G-Bild. Bei der korrekten Überlagerung 
von roter und grüner Ansicht kann im Prinzip 
jede der vier roten Helligkeitsstufen mit jeder 
der vier grünen Zusammentreffen. Insgesamt 
können also 16 Mischfarben im überlagerten 
Monitorbild auftreten. 

Rot- und Grünanteil der Mischfarben ent¬ 
sprechen jeweils den Helligkeitsstufen im 
roten und grünen Teilbild. Ein Trick macht es 
möglich, diese Mischfarben auf den Bild¬ 
schirm zu bringen, ohne daß die Überlap¬ 
pungsflächen explizit mit einem Stift der ent¬ 


sprechenden Farbe gezeichnet werden müß¬ 
ten. Der Trick besteht darin, die für die Dar¬ 
stellung von 16 Mischfarben erforderlichen 4 
Bitplanes in zwei Gruppen zu je zwei Bitpla¬ 
nes aufzuteilen. Beim Zeichnen der roten 
Ansicht werden nun einfach die unteren bei¬ 


den Bitplanes schreibgeschützt, beim Zeich¬ 
nen der grünen entsprechend die oberen bei¬ 
den Planes. 

Den vier Helligkeitsstufen A bis D werden 
dabei die Stifte 15, 10, 5 und 0 zugeordnet. 
Obwohl explizit nur mit vier Stiften gezeich¬ 
net wird, entstehen durch die Bit-Maskierung 
im überlagerten Bild automatisch alle 16 
erforderlichen Mischfarben. Wenn man z.B 
im roten Teilbild eine Scheibe mit Stift 15 
zeichnet und diese Scheibe im grünen Teil¬ 
bild Flächen mit unterschiedlichen Grün-Hel¬ 
ligkeitsstufen bedeckt, erscheinen die 
Flächen durch die Bitmaskierung in der 
Überlagerung automatisch so, als wären sie 
mit Stift 12 bis 15 gezeichnet. Anhand der 
Spalte »Bitbelegung« in der Tabelle kann 
man sich das leicht verdeutlichen. Wenn die 
Amiga-Farbtabelle nach den Vorgaben in den 
Spalten R, G,B modifiziert ist, besitzen alle 
Mischfarben den richtigen Rot- und Grünan¬ 
teil und man erhält bei der Überlagerung ein 
korrektes R/G-3D-Bild. Der Blauanteil muß 
übrigens nicht unbedingt 0 sein. Er muß nur 
für alle 16 Mischfarben gleich sein. 

Demo-Programm 

Das Modula-2-Programm »RGDemo.mod« 
(Seite 18 bis 20, Programm und Quellcode 
auf der Diskette zum Heft) bringt das 
beschriebene Scheibchenarrangement auf den 
Bildschirm (Bild 2). Um eine Hidden-Line- 
Darstellung zu erzielen, werden weiter ent¬ 
fernte Scheiben vor den näher liegenden 
gezeichnet. Die Prozedur »SetWrMskO« 



Bild 3: Schnappschuß aus der 3-D-Würfel-Animation. Wie in Bild 2 ist eine R- 
G-Filterbrille für den 3-D-Eindruck erforderlich. 
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Händleranfragen erwünscht! 


PROFI - MIDITOWER- KOMPLETTSYSTEM 
inkl Shuttle 2000, kompletter Kabelsatz und 
230Watt TUV-Netzteil + Lüftersteuerregelung 
+ Einbaurahmen' 1 dm ftqa nn 


TOWER TABLE STATION 

(TTS) 


Tastatur-Gehäuse 

für A500/S00+ und AI 200 


2.5" FESTPLATTEN von TOSHIBA 


KOMPLETTSYSTEM AI200 


* Daientedmik GmbH 

AIIX Vertrieb von 
JlWMmIMl Software und PD 

Postfach 710462 

2000 Hamburg 71 


Tel:040/6428225 
Tel:040/6426913 
Fax:040/6426913 


NEU! - "Vertrieb-jetzt 
direkt vom Herste ler" 


Vorrätige Lagerware verläßt noch am Tag des 
Bestelleingangs unser Haus ca. (95%) 
Versand auch Samstags vormittag . 


Bei Vorkasse plus DM 4,- 
Bei Vorkasse ab DM 200,- 
Warenwert ohne Vorkassegebühr. 
Bei Nachnahme plus DM 8,- 


> SHUTTLE 2000 - KIT 

100% AMIGA 2000er kombatible 

> 5x100 Zorro-Steckplätze (A2000) 
MMU-Steckplatz für Turbokarte (GVP...) 
Video-Steckplatz für Flickerfixer, 

Genlock.. 

4x16 Bit AT BUS-Steckplatze 
AT-Tastaturchipsatz nachrOstbar 
Floppy-Controller ON BOARD 

I OIE KOMPLETTLOSUNG 1 l 35 ' 

Der PROFI MIDI-TOWER 

FÜR AMIGA A500 /A500 + / AI200 
Spezialkonstruktion zum Einbau von A500, 
A500+ und AI 200,sowie dem Shuttle 2000 
und Leistungsstarkem Netzteil (220 Watt). 
Inklusiver ausführlicher Montageanleitung 


* Directory Opus 4.0 dt. 119y 

TruePrint24 129,- 


AMOS Creator deutsch 95, 

MOS Professional 139, 


X-Copy Pro. Tools dt. 74,' 
Euroübersetzer deutsch 79,< 


* Maxon Word deutsch 269, 

Morph Plus 339,- 




DER PROFI BIG-TOWER 

FÜR AMIGA A500 / A500+ / A1200 
A2000 / A2500 / A3000 / A4000 

Für sämtliche Amiga Modelle modifiziert 
Einfacher Umbau. Benötigte Kabel sind 
im Lieferumgang enthalten.7 Einschübe 
Inklusiv ausführlicher Montageanleitung 
und Einbaurahmen für int. 3 1/2" FDD. 

A500 (♦) - Tower DM 348,00 

A1200 - Tower DM 348,00 

A2000 - Tower DM 398,00 

A3000 - Tower auf Anfrage 

A4000 . Tower auf Anfrage 

Farbwahl optional auf Anfrage. 


incl. 3 , 5 " SONY MFD 2 DD 

Markendiskette je Disk 


Angebot freibleibend, Lieferung solange Vorrat reicht. Preise in DM. Preisinderungen durch Wechselkursinderungen kurzfristig 
möglich. AMIGA ist ein eingetragenes Warenzeichen von Commodore Büromaschinen GmbH, dt - Programm und/oder Handbuch i 
deutsch. • Bei Anzeigenschluß noch nicht lieferbar, rufen Sie uns bevor Sie es bestellen wollen an und Informieren Sie sich bei uns 


Flickerfix er-Aktion! 

MuHiVision 500 o. ,2000 + pass. 14' VGA-Cdor-Monitor* 

^Software i Paketpreis nur tyjf) r 


SyncMaster-: 

600 non Wertacad 0.31 


m. Wetten 


AMIGA Sounder, 327 S., 
inkl. 2 Disk.+ Hatine 
f. Digitizer-Selbstbau 49, 
3D-Sprinter, E5 S., Inler- 
akt. Echtzeitanimation, 
inkl. 2 Disk, nur noch 39. 
ARexx auf dem AMIGA, 
168 S., inkl. Disk, nur 29. 
Oder alle 3 Titel (!) (\Q 
für sagenhafte t* 


Auch A-TOO. A-2000 A !! 
A-2000 B, C A-50CX+), 600 
Jetzt antragen !!! 


SAFE THE BOARD 

(STB) 

Mit der "Safe the Board 
Serie" ist die Benutzung 
des A2000 unmöglich, 
es sei den, man hat den 
richtigen Schlüssel 

STB I 69,00 

rret SchiOaaatachaRar 

STB II 199,00 

mit Codeachtoß 

STB III 179,00 

mrt Schackkart enschioß 


Für jeden Tower-User und 
Ordnungsnarr ein Muß !!...! 
Der Monitorständer mit 
dem integriertem Maus 
Joystick- und Tastatur¬ 
anschluß. Nur ein Zen¬ 
trales Kabel (ca. 2m) 
führt zu Ihrem / 
Gehäuse 98 


APOLLO 2000 Filecard. 
SCSI/AT/2-8 MB RAM 339, 
APOLLO 500 379,- 

APOLLO AT-Bus A 500 249, 
APOLLO AT-Bus A2000 199, 

Supra XP500, 2/4/8 MB 
RAM-Opt.+SCSI+Busd. 398,- 
SUPRA SCSI f. A-2000 229,- 
Seagate 48 MB SCSI 329,- 
Quantum 2Ü MB t ms 949,- 
Seaaate 700 MB 5,25' 1999 
Blizzard-Turbo m. 2 MB 429, 
Personal Palnt, neues Super¬ 
grafikprogramm nur 99,- 


SHUTTLE 2000 

Komplett-System 

Shuttle 2000 - KIT im 
Desktop -Gehäuse 
220 Watt-Netzteil mit 
A500 Stromanschluß 
Kabel+Schraubensatz 


INDUSTRIE - QUALITÄT! 
Ora. A2000 Tastatur-Design 
jedoch stabilere Ausführung 
Farbwahl optional! 

ohn« Tastaturlabel 


Speichererweiterung von 
512 KB > 1 MB, nur mit 
Einbau, autoconflg., /V\ „ 
für nur noch 'Hl i 


DirectotyOpus deutsch 99, 


56 KHz HiR-Stereo- 
Sampler mit 
Soflwarepaket f 


Service 

48 Std M cig. Werkstal 


GENIAL FÜR A600/A1200 

86MB IDE 16ms- 598,00 
130MB IDE 16ms- 798,00 
213MB IDE 15ms - 1098,00 


AI 200 mit 86MB -1.548,00 
AI200 mit 130MB-1.798,00 
AI 200 mit 213MB -2.148,00 


PGC Peter Orühn Computertechnik PGC 

Münstersfr. 1414600 Dortmund 1 
Bestellservice: 0231 / 7 28 14 90 


JETZT KAUFEN UND 
SPÄTER ZAHLEN! 
WIR FINANZIEREN 
KOMPLETTSYSTEME 


eagle Computer products GmbH 
Altenbergstraße 7 • 7159 Auenwald 1 














GRUNDLAGEN 


erledigt die Bitmaskierung bei der R/G-Über- 
lagerung. Als Schmankerl folgt eine 3-D- 
Animation von zwei um den gemeinsamen 
Schwerpunkt rotierenden Würfeln. Eigentlich 
fehlt nur noch das Geräusch zersplitternden 
Glases, wenn die Würfel den Bildschirm 
durchschlagen. Um das Listing abdruckbar 
zu halten, haben wir darauf verzichtet. 

Damit der Bewegungsablauf der Anima¬ 
tion einigermaßen flüssig bleibt, berechnet 
der Amiga die umfangreichen Matrizenope¬ 
rationen im voraus und ruft bei der Darstel¬ 
lung der Szene nur noch die in einem 
ARRAY gespeicherten Ergebnisse ab. Um 
die Szene zu berechnen, braucht ein Amiga 
500 immerhin ca. zwei Minuten. ub 


Zusatzhardware 

Rot- und Grünfilter kann man zwar teuer 
beim Fotografen kaufen, aber billige Klar¬ 
sichtfolien aus dem Büromaterial-Fachge¬ 
schäft genügen vollkommen. Sie sollten nur 
darauf achten, daß rote und grüne Folie hin¬ 
tereinandergelegt völlig schwarz erscheinen, 
sonst werden die Teilbilder nicht sauber 
getrennt. Es ist auch möglich, daß die Far¬ 
ben der Filter nicht ganz genau zu den vom 
Monitor dargestellten Farben passen. In bei¬ 
den Fällen kann man die Filterwirkung ver¬ 
bessern, indem man mehrere Folien einer 
Farbe übereinanderschichtet. 


Grenzen: Da beim R/G-Verfahren die 
räumliche Tiefe durch den Abstand der Teil¬ 
bildkomponenten erzeugt wird, ist das Tie¬ 
fenauflösungsvermögen durch den Pixelab¬ 
stand am Bildschirm begrenzt. Das schränkt 
den Anwendungsbereich ein. Einen 3D- 
Solid-Model-Editor wird man nicht befriedi¬ 
gend realisieren können. Eher ist ein Einsatz 
im Multimedia- oder im Spielebereich denk¬ 
bar. Das R/G-Verfahren ist z.B. als Option 
zur Spielbrettdarstellung im Spielprogramm 
SOGO (Programm des Monats im AMIGA- 
Magazin 5/92) enthalten. Blockout wäre ein 
anderes R/G-3D-Projekt. Urteilen Sie 
selbst! Ist Rot/Grün eine Alternative? 



Bild 5: Ausschneidebogen 
für Rot-Grün-3-D-Brille 
zum Selberbasteln; R/G- 
Folien (Wangophan) sind 
erhältlich bei Fa. Kaut- 
Bullinger oder Fa. XYLO, 
(beide in München). 
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Endlich auch auf deutsch! 



’MtyuX' 


Wie erklärst du der Welt die Möglichkeiten in 
deiner Heimatstadt ? 


Cantrix 


CanDo 

INOVAtronics 


Score ETUI 
Level 

Lines_ 

UKttten by. Mx. Z2) 

Was ist so besonderes an diesem Spiel ? 


}| Rectoiuntfoster 1.68 (12.8.31) 

Sold T «: ■ 1 '' "w r- 


riiäii 
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jlCanbo T-Shirt X-LBRBr 
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JL 
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Wie bewältigt ein stetig wachsender Software- 
Hersteller all diese-Rechnungen ? 


Wie beschäftigst du deine Kinder an einem 
regnerischen Samstag-Nachmittag ? 


CanDo macht Ideen wahr. 


Szenario I: Du sitzt an deinem Amiga und fragst 
dich warum es kein Datenbank/Quizprogramm gibt 
(das Kinder lieben würden). Die Zeit verrinnt. 
Frustration setzt ein. 

Szenario II: Du hast dir gerade ein hervorragen¬ 
des Programm ausgedacht - als CanDo-Besitzer 
erstellst du es selber: Fenster, Fonts, Menus, 
Animationen, Sound und vieles mehr, alles unter 
deiner Kontrolle! 

Immernoch unsicher? 

Dann mach die CanDo-Probefahrt und entdecke, 
warum bereits tausende von Amiga-Besitzern in 
den USA täglich mit CanDo arbeiten. Das CanDo- 
Testdrive kostet nur 29 DM (Demoversion). Und 
weil wir wissen, daß dir CanDo gefallen wird, 
nehmen wir dein Testdrive voll in Zahlung! 


CanDo bietet Lösungen! 

Das besondere an CanDo ist, daß du mit minima¬ 
lem Zeitaufwand, exakt das bekommst, was du 
willst. Wenn du ein "richtiger" Programmierer 
bist, bedenke daß mit CanDo viele große Projekte 
schnell und einfach erledigt sind. 

Los geht’s. Probier es aus! 

Wir sind sicher, daß du CanDo lieben wirst. CanDo 
bringt dich schneller ans Ziel. 


CanDo V2.0 nur 299 DM! 

INOVAtronics 


Be More Productive. 


Inovatronics GmbH, Im Heidkamp 11, 5000 Köln 91, Tel: 0221-875 126, Fax: 0221-870 4747 
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mögliche Kombinationen bei der Überlagerung von roter und grüner Ansicht 

Komponenten der 

Mischfarbe 

Bitbelegung 

Pen 

nr. 

Helligkeit im roten Teilbild 

Helligkeit im grünen Teilbild 

hell 

halb 

hell 

halb 

dunkel 

dunkel 

hell 

halb 

hell 

halb 

dunkel 

dunkel 

R 

% 

G 

% 

B 

% 

Bitmap 

rot 

Bitmap 

grün 

■ 

X 




X 




100 

100 

0 

■■ 

1 

1 

1 

15 

X 





X 



100 

66 

0 

1 

n 

1 

0 

14 

■■ 






X 


100 

33 

0 

n 

1 

0 

1 

13 

m» 







X 

100 

0 

0 

1 

1 

0 

0 

12 


X 



X 




66 

100 

0 

1 

0 

1 

1 

11 


X 




X 



66 

66 

0 

1 

0 

1 

0 

10 


X 





X 


66 

33 

n 

1 

0 

0 

1 

9 


X 






X 

66 

0 

D 

i 

0 

0 

0 

8 



X 


X 




33 

100 

0 

0 

D 

1 

1 




X 



X 



33 

66 

0 

0 

n 

1 

0 




X 




X 


33 

33 

0 

0 

n 

0 

1 

5 



X 





X 

33 

0 

0 

0 

l 

0 

0 

4 




X 

X 




0 

100 

0 

0 

0 

1 

1 

3 




X 


X 



0 

66 

0 

0 

0 

1 

0 

2 




X 



X 


0 

33 

0 

0 

0 

0 

n 

1 




X 




X 

0 

0 

0 

0 

0 

0 

TI 

0 

15 

10 

5 

0 

15 

10 

5 

0 


für die 4 R/G-Helligkeitsstufen explizit verwendete Pen-Nummern 


Bild 4. Die geeignete Belegung der Farbtabelle ergibt zusammen mit der Bit-Maskierung automatisch eine korrekte Über¬ 
lagerung von rotem und grünem Teilbild 


1 

M0DULE RGDemo; 

29 

RGScreenPtrO : ScreenPtr; 

2 


30 

RGWindowPtrl : WindowPtr; 

3 

FR0M SYSTEM IMPORT ADDRESS,ADR,INLINE,FFP; 

31 

RGScreenPtrl : ScreenPtr; 

4 

FR0M Intuition IMPORT NewWindow,IDCMPFlags,IDCMPFlagSet,ScreenPtr,W 

32 

RGWinRPPtrO : RastPortPtr; 


indowPtr,WindowFlags,WindowFlagSet,NewScreen,customScreen,OpenScree 

33 

RGWinRPPtrl : RastPortPtr; 


n,CloseScreen,OpenWindow,CloseWindow,ScreenFlags,ScreenFlagSet,Intu 

34 

RGRPPtr : RastPortPtr; 


iMessagePtr,ScreenToFront; 

35 

Buffer : ARRAY[0..49] OF CARDINAL; 

5 

FROM Graphics IMPORT AllocRaster,TrapRas,Areainfo,AreaEIlipse,AreaM 

36 

AreaMemPtr : ADDRESS; 


ove,Text,AreaDraw,AreaEnd,BitMap,InitBitMap,ViewModeSet,ViewModes,F 

37 

RGDemoTmpRas : TmpRas; 


reeRaster,DrawEllipse,SetRast,Move,InitArea,InitTmpRas,LoadRGB4,Set 

38 

RGDemoArealnfo : Areainfo; 


APen,InitRastPort,RastPort,RastPortPtr,Draw; 

39 

IntuiMsg,IntuiMsgl ; IntuiMessagePtr; 

6 

FROM GfxMacros IMPORT SetWrMsk,SetOPen? 

40 

ok,EX,ausserhalb : BOOLEAN; 

7 

FROM Exec IMPORT GetMsg,ReplyMsg; 

41 

dass : IDCMPFlagSet; 

8 

FROM InOut IMPORT WriteString,WriteLn; 

42 


9 

FROM Arts IMPORT TermProcedure; 

43 

WPlorg : Ecken; (* Ecken d. 1.Würfels original *) 

10 

FROM RandomNumber IMPORT RND,PutSeed; 

44 

WP1 : Ecken; (* transformiert *) 

11 

FROM MathLibFFP IMPORT sin,cos,pi; 

45 

WP2org : Ecken; (* 2. original *) 

12 


46 

WP2 : Ecken; (* transformiert *) 

13 

CONST rotsteps = 360; (* Anzahl der Rot.schritte der Würfe 

47 

F : ARRAYI1..6],[1..5] OF INTEGER; (* Würf.flächn *) 


lanimation *) 

48 

FIndexWl : Flaechenlndex; {* Numerierung der Flächen *) 

14: 

: p = 0.2; (* Perspekt. Verkürzungsfaktor *) 

49 

FIndexW2 : Flaechenlndex; 

15; 

alfa = -70.0*pi/180.0; (* Winkel, unter dem die Rotation 

50 

ZFCW1 : ZvonFCenter; (* z-Koordinaten der Würf.flächn *) 


s- 

51 

ZFCW2 ; ZvonFCenter; 

16: 

i ebene der Würfelanim, ges 

52 

Trafo : ARRAY[1..3],[1..3] OF FFP; {* Rot. matrix *) 


ehen wird *) 

53 

ARInt : ARRAY[1..108*rotsteps] OF INTEGER; (* Animat.*) 

17: 

: dphi = pi/180.0; (* Rotationswinkel-Inkrement *) 

54 

11 : LONGINT; (* Index für ARInt *) 

18: 

: XShift = 320; (* Offset, um die Animation in die Bildschirm- 

*) 

55 

cc 

RGDelta ; FFP; (* Faktor für Rot/Grün-Versatz *) 

19 

YShift = 128; (* mitte zu rücken *) 

jD 

57 

PROCEDURE CloseDown ; (* räumt zum Schluß alles auf *) 

20 

ZFocus = 1000.0; (* z-Koord. d. Fluchtpunktes (OIOIZFocus) *) 

58 

VAR i,j : INTEGER; 

21 


59 

BEGIN (* CloseDown *) 

22 

TYPE Ecken = ARRAY[1..8],[1..3] OF FFP; 

60 

IF RGWindowPtrO # NIL THEN CloseWindow(RGWindowPtrO); END; 

23 

Flaechenlndex = ARRAY[1..6] OF INTEGER; 

61 

IF RGScreenPtrO # NIL THEN CloseScreen(RGScreenPtrO); END; 

24 

ZvonFCenter = ARRAY[1..6] 0F FFP; 

62 

IF RGWindowPtrl # NIL THEN CloseWindow(RGWindowPtrl); END; 

25 


63 

IF RGScreenPtrl # NIL THEN CloseScreen(RGScreenPtrl); END; 

26 

VAR RGWindow : NewWindow; 

64 

IF AreaMemPtr # NIL THEN FreeRaster(AreaMemPtr,640,256); EN 

27 

RGScreen : NewScreen; 


D; 

28 

RGWindowPtrO : WindowPtr; 

65: 

; END CloseDown ; 
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66 


149: 

FOR i:=l TO 2*max DO 

67 

PROCEDURE Okay(text : ARRAY OF CHAR ; adr : ADDRESS):BOOLEAN ; 

150: 

ausserhalb:=TRUE; 

68 

BEGIN (* Okay *) 

151: 

WHILE ausserhalb DO 

69 

IF adr = NIL THEN 

152: 

x:=l+RND(640);y:=1+RND(256); 

70 

WriteString(text);WriteString(" läßt sich nicht oeffnen !!") ; 

153: 

IF i<max THEN deltarot:=max-i;deltagruen:=0;k:=max-i;r:=20+ 


WriteLn ; 


i DIV 2; 

71 

WriteStringC ProgrammABBRUCH") ; WriteLn ; RETURN (FALSE) ? 

154: 

ELSE deltarot:=0;deltagruen:=i-max;k:=i-max;r:=2 0+ 

72 

ELSE RETURN(TRUE); END (* IF *) ; 


i DIV 2; 

73 

END Okay ; 

155 

END; 

74 


156 

IF (2+2*r+k<x) AND (638-2*r>x) 

75 

PROCEDURE InitOberfl; (* initialisiert 2 Screens etc. für DoubleBuf 

157 

AND (2+r <y) AND (240-r >y) THEN 


fering *) 

158 

ausserhalb:=FALSE; 

76 

VAR i,j :INTEGER; 

159 

END; 

77 

BEGIN 

160 

END; 

78 

RGScreenPtrO:=NIL; RGWindowPtrO:=NIL; 

161 

Pen:=5*CARDINAL(RND(3)+1); 

79 

RGScreenPtrl:=NIL; RGWindowPtrl:=NIL; AreaMemPtr:=NIL; 

162 


80 


163 

FOR k:=0 TO 49 DO Buffer[k]:=0;END; 

81 

WITH RGScreen DO 

164 

(* rote Ansicht zeichnen *) 

82 

leftEdge := 0 ; topEdge := 0 ; width := 640 ; height := 256 ; 

165 

SetAPen(RGWinRPPtrl,Pen); SetWrMsk(RGWinRPPtrl,0F3H); 


depth := 4 ; 

166 

ok:=AreaEllipse(RGWinRPPtrl,x-deltarot,y,2*r,r); 

83. 

detailPen := 0 ; blockPen := 1 ; viewModes : = ViewModeSet{hir 

167 

ok:=AreaEnd(RGWinRPPtrl); 


es) ; 

168 

SetAPen(RGWinRPPtrl,0); 

84 

type := customScreen; font := NIL ; defaultTitle :=ADR("NIL") 

169 

DrawEl1ipse(RGWinRPPtrl,x-deltarot,y,2 *r,r); 



170 

(* grüne Ansicht zeichnen *) 

85 

gadgets : = NIL ; customBitMap : = NIL; 

171 

SetAPen(RGWinRPPtrl,Pen);SetWrMsk(RGWinRPPtrl,0FCH); 

86 

END (* WITH *) ; 

172 

FOR k:=0 TO 49 DO Buffer[k]:=0;END; 

87 


173 

ok:=AreaEllipse(RGWinRPPtrl,x-deltagruen,y,2*r,r); 

88 

RGScreenPtrO := OpenScreen(RGScreen) ; 

174 

ok:=AreaEnd(RGWinRPPtrl); 

89 

IF NOT Okay("RGScreen*,RGScreenPtrO) THEN CloseDown;HALT;END; 

175 

SetAPen(RGWinRPPtrl,0); 

90 


176 

DrawEl1ipse(RGWinRPPtrl,x-deltagruen,y,2 *r,r) 

91 

WITH RGWindow DO 

177 

END; 

92 

leftEdge:=0; topEdge:=l; width:=640; height:= 255; 

178 

SetWrMsk(RGWinRPPtrl,0FFH);SetAPen(RGWinRPPtrl,15); 

93 

detailPen:=9; blockPen:=15; idcmpFlags:=IDCMPFlagSet{closeWindo 

179 

Move(RGWinRPPtrl,20,10);Text(RGWinRPPtrl,ADR 


w}; 

180 

("AMIGA berechnet jetzt die Würfelanimation, bitte ca. 2 min. warte 

94 

flags:=WindowFlagSet{windowClose,gimmeZeroZero,activate}; 


n...*),69); 

95 

firstGadget:=NIL; checkMark:=NIL; title:=ADR("Rot-Grün-3D-Demo 

181 

END ScheibenZeichnen; 


0"); 

182 


96 

bitMap:=NIL; type:=customScreen; screen:= RGScreenPtrO; minWidt 

183 

PROCEDURE AnimWuerfel; 


h:=600; 

184 

VAR i,j,k,n : INTEGER; 

97 

maxWidth:=640; minHeight:=256; maxHeight:=256; 

185 

m : LONGINT; 

98 

END; 

186 


99 


187 

PROCEDURE QuickSort(1,r:CARDINAL;VAR Wt:ZvonFCenter;VAR FI:Flaechen 

100 

RGWindowPtrO:=OpenWindow(RGWindow); 


Index); 

101 

IF NOT Okay("RGWindow",RGWindowPtrO) THEN CloseDown;HALT;END; 

188: (* sortiert für die Hiddenlme Darstellung die Flächen nach der z-K 

102 

RGWinRPPtrO:=RGWindowPtrO A .rPort; 


oordinate 

103 


189 

des Flächenzentrums *) 

104 

RGScreenPtrl := OpenScreen(RGScreen) ; 

190 

VAR i,j : CARDINAL; 

105 

IF NOT Okay("RGScreen",RGScreenPtrl) THEN CloseDown;HALT;END; 

191 

Ind : INTEGER; 

106 


192 

x,y : FFP; 

107 

WITH RGWindow DO 

193 

BEGIN 

108 

title:=ADR("Rot-Grün-3D-Demo 1"); screen:= RGScreenPtrl; 

194 

i:=l;j:=r; x:=Wt[(l+r) DIV 2]; 

109 

END; 

195 

REPEAT 

110 


196 

WHILE Wt[i]<x DO INC(i) END; WHILE x<Wt[j] DO DEC(j) END; 

111 

RGWindowPtrl:=OpenWindow(RGWindow); 

197 

IF i<=j THEN 

112 

IF NOT Okay("RGWindow",RGWindowPtrl) THEN CloseDown;HALT?END; 

198 

y:=Wt[i]; Ind:=FI[i]; 

113 

RGWinRPPtrl:=RGWindowPtrl A .rPort; 

199 

Wt[i]:=Wt[j]; FI[i]:=FI[j]; 

114 


200 

Wt[j]:=y; FI[j):=Ind; 

115 

RGRPPtr:=RGWinRPPtrO; 

201 

INC(i); DEC(j); 

116 


202 

END; 

117 

AreaMemPtr:=AllocRaster(640,256) ; 

203 

UNTIL i>j; 

118 

IF NOT Okay("AreaMem",AreaMemPtr) THEN CloseDown; HALT;END; 

204 

IF l<j THEN QuickSort(l,j,Wt,FI) END? 

119 

FOR i:=0 TO 49 DO Buffer[i]:=0;END; 

205 

IF l<r THEN QuickSort(i.r.Wt.FI) END? 

120 

InitArea(RGDemoArealnfo,ADR(Buffer),20); (* Areainfo initialisi 

206 

END QuickSort; 


eren *) 

207 


121 

: InitTmpRas(RGDemoTmpRas,AreaMemPtr,20480); (* TmpRas initialisier 

208 

PROCEDURE RechneARInt(VAR WP:Ecken;VAR PI,P2,P3,P4,Pen:INTEGER); 


en *) 

209 

(* Berechnet die Animationssequenz im voraus und speichert alles in 

122: RGWinRPPtrO A .tmpRas:=ADR(RGDemoTmpRas); (* TmpRas übergeben *) 


ARInt *) 

123: RGWinRPPtrO A .areaInfo:=ADR(RGDemoArealnfo);(* Areainfo übergeben 

210 

VAR j :INTEGER; 


*) 

211 

BEGIN 

124 

: RGWinRPPtrl A .tmpRas:=ADR(RGDemoTmpRas); (* TmpRas übergeben *) 

212 

ARInt[11]:=Pen;INC(Il); 

125 

: RGWinRPPtr1 A .arealnfo:=ADR(RGDemoArealnfo);(* Areainfo übergeben 

213 

ARInt[11]:=INTEGER(WP[PI][1]*(ZF0CUS-WP[P1][3])/ZFocus 


*) » 

214 

+RGDelta*WP[Pl][3]+0.5)+XShift; INC(11); 

126 


215 

ARInt[11]:=INTEGER(WP[P1][2]*(ZFocus-WP[Pl][3])/ZFocus) DIV 2 +YS 

127 

: PutSeed(2); 


hift;INC(11); 

128 

: END InitOberfl; 

216 

: ARInt[11]:=INTEGER(WP[P2][1]MZFocus-WP[P2][3])/ZFocus 

129 


217 

: +RGDelta*WP[P2][3]+0.5)+XShift; INC(Il); 

130 

: PROCEDURE FarbTabelle;(* $E- *) 

218 

: ARInt[11]:=INTEGER(WP[P2][2]*(ZFocus-WP[P2][3])/ZFocus) DIV 2 +YS 

131 

: BEGIN 


hift;INC(11); 

132 

: INLINE(0007H,0057H,0077H,0097H, 

219 

: ARInt[11]:=INTEGER(WP[P3][1]*(ZFocus-WP[P3][3])/ZFocus 

133 

: 0507H,0557H,0577H,0597H, 

220 

: +RGDelta*WP[P3][3]+0.5)+XShift; INC(Il); 

134 

: 0707H,0757H,0777H,0797H, 

221 

: ARInt[11]:=INTEGER(WP[P3][2]*(ZFocus-WP[P3][3])/ZFocus) DIV 2 +YS 

135 

: 0907H,0957H,0977H,0997H); 


hift;INC(11); 

136 

: END FarbTabelle; 

222 

: ARInt[11]:=INTEGER(WP[P4][1]*(ZFocus-WP[P4][3])/ZFocus 

137 


223 

: +RGDelta*WP[P4][3]+0.5)+XShift; INC(11); 

138 

: PROCEDURE FarbTabelleLaden; 

224 

: ARInt[11]:=INTEGER(WP[P4][2]*(ZFocus-WP[P4][3])/ZFocus) DIV 2 +YS 

139 

: BEGIN 


hift; 

140 

: LoadRGB4(ADR(RGWindowPtrO A .wScreen A .viewPort),ADR(FarbTabelle),16) 

225 

: IF Il<108*rotsteps THEN INC(Il) 


; 

226 

: ELSE 11**1 

141 

: LoadRGB4(ADR(RGWindowPtrl A .wScreen A .viewPort),ADR(FarbTabelle),16) 

227 

: END; 

142 

: END FarbTabelleLaden; 

228 

: END RechneARInt; 

143 


229 


144 

: PROCEDURE ScheibenZeichnen; 

230 

: BEGIN 

145 

: VAR i,k,r,x,y,deltarot,deltagruen,max : INTEGER; 

231 

: Il:=l; RGDelta:=0.04; 

146 

Pen : CARDINAL; 

232 


147 

: BEGIN 

233 

: (* Definition der Würfelflächen anhand der aufspannenden Ecken *) 

148 

: max:=20; 

234 

: F[l][1]:=1; F[l][2]:=2; F[l][3]:=3; F[l][4]:=4; F[l][5]:=5; 
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235 

F[2][1]: = 1; F[2][2]:=2; F[2][3 

:=6; F(2][4]:=5; F[2][5] 

=5; 

325 


236 

F[3H11:-2; F[3][2]:=3; F[3][3 

:=7; F[3][4]:=6; F[3][5] 

=10; 

326: (* für beide Würfel die sichtbaren drei Flächen im Anim-speicher ab 

237 

F[4] [1]:=1; F[4][2]:=4; F[4][3 

:=8; F[4][4]:=5; F[4][5] 

=5; 


legen *) 

238 

F[5][1]:=3; F[5][2]:=4; F[5][3 

:=8; F[5)[4]:=7; F[5][5] 

=5; 

327 

LOOP 

239 

F[6] [1]:=5; F[6][2]:=6; F[6][3 

:=7; F(6][4]:=8; F[6][5] 

=10; 

328 

IF ZFCW2[1]<ZFCW1f1] THEN 

240 





329 

FOR i:=3 TO 1 BY -1 DO 

241 

(* Koordinaten der Würfelecken im KO-System 2; 



330 

j :=FIndexWl [i] ,* 

242 

KO-System 1: Ursprung: linke obere Bildschirmecke; 


331 

RechneARInt(WPlorg,F[j,1],F[j,2],F[j,3],F[j,4],F[j,5]); 

243 

x-Achse: oberer Bildschirmrand links -> rechts; 

332 

END; 

244 

y-Achse: linker Bildschirmrand oben 

-> unten; 

333 

FOR i:=3 TO 1 BY -1 DO 

245 

z-Achse: in Blickrichtung in den Bildschirm hinein 

334 

j:=FIndexW2[i]; 

246 

KO-System 2: geht aus KO-System 1 durch Drehung um alfa um die x-Ac 

335 

RechneARInt(WP2org,F[j,l],F[j,2],F[j,3],F[j,4],F[j,5]); 


hse hervor *) 




336 

END; 

247 





337 

ELSE 

248 

WPlorgfl,1]:=-1.5; WPlorgfl,2] 

= 1.0; WPlorgfl,3] 

=-1.0 


338 

FOR i:=3 TO 1 BY -1 DO 

249 

WPlorg[2,l]:=-3.5; WPlorg[2,2] 

= 1.0; WPlorg(2,3] 

=-1.0 


339 

j:=FIndexW2[i]; 

250 

WPlorg[3,1]:=-3.5; WPlorg[3,2] 

=-1.0; WPlorg(3,3] 

=-1.0 


340 

RechneARInt(WP2org,F(j,1],F[j,2],F[j,3],F[j, 4],F[j, 51); 

251 

WPlorg[4,L]:=-1.5; WPlorg(4,2] 

=-1.0; WPlorg[4,3] 

=-1.0 


341 

END; 

252 

WPlorg[5 ( 1]:=-1.5; WPlorg[5,2] 

= 1.0; WPlorg(5,3] 

= 1.0 


342 

FOR i:=3 TO 1 BY -1 DO 

253 

WPlorg[6,1]:=-3.5; WPlorg[6,2] 

= 1.0; WPlorg(6,3] 

= 1.0 


343 

j:=FIndexWl[i]; 

254 

WPlorg[7,1]:=-3.5; WPlorg[7,2] 

=-1.0; WPlorg[7,3] 

= 1.0 


344 

RechneARInt(WPlorg,F[j,1],F[j,2],F[j,3],F[j,4],F[j,5]); 

255 

WPlorg[8,1]:=-1.5; WPlorg[8,2] 

=-1.0; WPlorg(8,3] 

= 1.0 


345 

END? 

256 

FOR i:=l TO 8 DO 




346 

END; 

257 

WP2org[i](1):=WPlorg[i][l]+5.0; 



347 


258 

WP2org[i)[2]:=WPlorg[i][2] 

WP2org[i][3]:=WPlorg[i][3]; 

348 

IF n=2 THEN 

259 

END; 




349 

EXIT 

260 





350 

ELSE 

261 

(* Vergrößerungsfaktor anbringen 

*) 



351 

INC(n); RGDelta:=-RGDelta; 

262 

FOR i:=l TO 8 DO FOR j:=l TO 3 DO 



352 

END; 

263 

WPlorg[i,j]:=WPlorg[i,j]*45.0; WP2org[i,j]:=WP2org[i,j]*45.0; 

353 

END; 

264 

END; END; 




354 

END; 

265 





355 


266 

(* Koordinaten in KO-System 1 umrechnen *) 



356 

n:=l; 

267 

Trafo[1,1):= 1.0; Trafo[l,2]:= 

0.0; Trafofl,3]:= 0.0; 

357 

SetWrMsk(RGRPPtr,0FFH); SetRast(RGRPPtr,0); 

268 

Trafo[2,1]: = 0.0; Trafo[2,2]:= 

cos(alfa); Trafo[2,3]:=-sin(alfa); 

358 

m:=-8; 

269 

Trafo[3,1]:= 0.0; Trafo[3,2]:= 

sin(alfa); Trafo[3,3]:= cos(alfa); 

359 


270 

FOR i:=1 TO 8 DO FOR j:=l TO 3 

DO 



360 

(* Animation zeichnen *) 

271 

WP1[i,j]:=0.0? WP2(i,j]:=0 

0; 



361 

LOOP 

272 

END; END; 




362 

INC(m,9); 

273 

FOR i:=l TO 8 DO FOR j:=l TO 3 

DO FOR k:=l TO 3 DO 


363 

IF m+8>108*rotsteps THEN m:=l END; 

274 

WP1[i,j]:=WP1[i,j]+Trafo[j,k]*WPlorg[i,k]; 



364 

IF (n=l) THEN SetWrMsk(RGRPPtr,0F3H);SetOPen(RGRPPtr,10); END 

275 

WP2[i,j]:=WP2[i,j]+Trafo[j,kj*WP2org[i,kj; 




; 

276 

END; END; END; 




365 

IF (n=7) THEN SetWrMsk(RGRPPtr,0FCH)?SetOPen(RGRPPtr,10); END 

277 

FOR i:=l TO 8 DO FOR j:=l TO 3 

DO 




; 

278 

WPlorg[i,j]:=WP1[ i, j ]; WP2org[i,j]:=WP2[ i, j ]; 



366 

FOR j:=0 TO 49 DO Buffer[j]:=0;END; 

279 

END; END; 




367 

SetAPen(RGRPPtr,ARInt[m]); 

280 





368 

ok:=AreaMove(RGRPPtr,ARInt[m+1],ARInt[m+2]); 

281 

(* Matrix für die Rotation der Würfel um dphi um die z-Achse von KO 

369 

ok:=AreaDraw(RGRPPtr,ARInt[m+3],ARInt[m+4]); 


-System 2 *) 




370 

ok:=AreaDraw(RGRPPtr,ARInt[m+5],ARInt[m+6])? 

282 

Trafo[l,l]:= cos(dphi); 




371 

ok:=AreaDraw(RGRPPtr,ARInt[m+7],ARInt[m+8]); 

283 

Trafo[l,2]:= cos(alfa)*sin(dphi); 



372 

ok:=AreaEnd(RGRPPtr); 

284 

Trafo[1,3]: = sin(dphi)*sin(alfa); 



373 

IF (n=12) THEN 

285 

Trafo[2,1]:= -cos(alfa)*sin(dphi)? 



374 

n:=0; 

286 

Trafo[2,2]:= cos(alfa)*cos(alfa)*cos(dphi)+sin(alfa)*sin(alf 

375 

IF (RGRPPtr=RGWinRPPtrl) THEN 


a); 




376 

RGRPPtr:=RGWinRPPtrO;ScreenToFront(RGScreenPtrl); 

287: 

Trafo[2,3]:= cos(alfa)*cos(dphi)*sin(alfa)-sin(alfa)*co 

377 

ELSE 


s(alfa); 




378 

RGRPPtr:=RGWinRPPtrl;ScreenToFront(RGScreenPtrO); 

288: 

Trafo[3,l]:=-sin(alfa)*sin(dphi); 



379 

END; 

289: Trafo[3,2]:= sin(alfa)*cos(alfa)*cos(dphi)-cos(alfa)*sin(alf 

380 

SetWrMsk(RGRPPtr,0FFH); SetRast(RGRPPtr,0); 


a); 




381 

END; 

290 

Trafo[3,3]:= sin(alfa)*sin(alfa)*cos(dphi)+cos(alfa)*co 

382 

INC(n); 


s(alfa); 




383 


291 





384 

EX:=FALSE; 

292 

FOR m:=l TO rotsteps DO 




385 

IF (RGWindowPtrO # NIL) THEN 

293 





386 

IntuiMsg:=GetMsg(RGWindowPtrO A .userPort); 

294 

(* neue Koordinaten nach der Rotation um dphi berechnen * 


387 

WHILE IntuiMsg#NIL DO 

295 

FOR i:=1 TO 8 DO FOR j:=l TO 3 DO 



388 

dass:=IntuiMsg A .dass? ReplyMsg(IntuiMsg) ; 

296 

WP1[i,j]:=0.0; WP2[i,j]: 

=0.0; 



389 

IF (closeWindow IN dass) THEN EX:=TRUE?END; 

297 

END; END; 




390 

IntuiMsg:=GetMsg(RGWindowPtrO A .userPort); 

298 

FOR i:=l TO 8 DO FOR j:=l TO 3 DO FOR k:=l TO 3 

DO 


391 

END; 

299 

WP1[i,j]:=WP1[i,j]+Trafo[j,k]*WPlorg[i,k]; 



392 

END; 

300 

WP2[i,j]:=WP2[i,jj+Trafo[j,kj*WP2org[i,kj; 



393 

IF (RGWindowPtrl # NIL) THEN 

301 

END; END; END; 




394 

IntuiMsg:=GetMsg(RGWindowPtrl A .userPort); 

302 

FOR i:=1 TO 8 DO FOR j:=l TO 

3 DO 



395 

WHILE IntuiMsg#NIL DO 

303 

WPlorg(i,j):=WPl[i,j]; WP2org[i,j]:=WP2[i,j]? 


396 

dass :=IntuiMsg A . dass; ReplyMsg (IntuiMsg); 

304 

END; END; 




397 

IF (closeWindow IN dass) THEN EX:=TRUE;END; 

305 





398 

IntuiMsg:=GetMsg(RGWindowPt rl A .userPort); 

306 

(* Abstand der Flächenzentren vom Betrachter berechnen *) 


399 

END; 

307 

FOR i:=l TO 6 DO 




400 

END; 

308 

j:=F[i,l]; k:=FIi,3); 




401 

IF EX THEN EXIT;END; 

309 

ZFCW1 [i] : = (WP1 [ j, 1] +WP1 [k, 1]) * (WP1 [ j, 1]+WP1 [k, 1]) 


402 

END; 

310 

(WPl[j,2]+WPl[k,2]) * (WP1 [j ,2]+WPl [k,2]) 


403 

END AnimWuerfel; 

311 

(WP1[j,3)+WP1[k,3]+50.0*ZFocus)* 



404 


312 

(WP1[j,3]+WP1[k,3]+50.0*ZFocus); 



405 

BEGIN 

313 

ZFCW2[i]:=(WP2[j,1]+WP2[k,1])*(WP2[j,1]+WP2[k,1])+ 

406 

WriteString(*Rot-Grün-3D-Demo Version 1.0,');WriteLn; 

314 

(WP2[j,2]+WP2[k,2]) *(WP2 fj,2]+WP2[k,2]) 


407 

WriteStringl'Copyright: Bernfried Brüggemann, Munich 22.04.92*);W 

315 

(WP2[j,3]+WP2[k,3]+50.0*ZFocus)* 




riteLn; 

316 

(WP2[j,3]+WP2[k,3]+50.0*ZFocus); 



408 

TermProcedure(CloseDown); 

317 

END; 




409 

InitOberfl; 

318 

FOR i:=l TO 6 DO FIndexWl[i] 

=i; FIndexW2[i]:=i 

END; 


410 

FarbTabelleLaden; 

319 





411 

Scheibenzeichnen; 

320 

(* Flächen für Hiddenline-Darstellung sortieren *) 



412 

AnimWuerfel; 

321 

QuickSort(1,6,ZFCW1,FIndexWl); QuickSort(1,6,ZFCW2,FIndexW2)? 

413 

END RGDemo. © 1993 M&T 

322 

323 

n:=l; 




»RGB_Demo.mod«: Das Modula-2-Programm (M2Amiga) stellt 

324 

RGDelta:=-RGDelta; 




Objekte per Rot-Grün-Verfahren dreidimensional dar 
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GRUNDLAGEN 


Ein praxisorientiertes Verfahren 

Zwei- und drei¬ 


dimensionales Clipping 


Wichtigste Aufgabe von Programmen ist es heute, den Bildschirm zu 
beschreiben, zu färben, zu zeichnen oder zu scrollen. Das Verhältnis zu 
den wenigen, die Motoren steuern, Meßwerte aufnehmen oder Impulse 
ausgeben, düifte ca. 9:1 sein. Grund genug, über effiziente Grafikver¬ 
fahren nachzudenken. Hier finden Sie leistungsfähige Algorithmen vor. 


D 


von Bernhard Einese 

( er Bildschirm ist des Computers lieb¬ 
stes Kind, und die Kunst des Erzeu¬ 
gens von Linien und Buchstaben ist 
gleichermaßen wichtig wie der wissenschaft¬ 
liche Dialog oder das Abballern feindlicher 
Raumschiffe. Doch auch hier werden zur 
Beherrschung manche Kniffe verlangt. Einer 
davon ist das »Clipping«. Darunter versteht 
man das rechtzeitige Abschneiden (Kappen) 
von Linien, falls diese über den Bildrand hin¬ 
auslaufen sollen. 

Gerade bei 3-D-Animationen, wo mit Hilfe 
der Maus jeder beliebige Blickwinkel einzu¬ 
stellen ist und das Objekt so vollständig aus 
dem Bild hinauslaufen kann, ist Clipping also 
unvermeidlich. Setzt man Clipping nicht ein, 
würden die Linien, die über den rechten Rand 
hinauslaufen, um eine Zeile nach unten ver¬ 
setzt am linken Rand wieder auftauchen. 
Verläßt darüber hinaus eine Linie am oberen 
oder unteren Rand den sichtbaren Bereich, 
schreibt man so Bilddaten außerhalb des 
Video-RAMs in verbotene Adressen, was 
üblicherweise zum Absturz führt. 



Bild 1: Das prinzipielle Vorgehen un¬ 
serer Funktion ClpBltBitMap - so 
überprüft sie die Dimensionen des zu 
kopierenden Bereichs 


Es genügt aber nicht, Linien und andere 
Bildelemente, die nur teilweise zu sehen sind, 
vollständig wegzulassen. Das Clippen zerlegt 
ein Objekt in sichtbare und unsichtbare Ele¬ 
mente und sorgt dafür, daß nur die sichtbaren 
gezeichnet werden. 

Doch wofür eigentlich noch 2-D-Clipping, 
schließlich ist es doch schon Bestandteil des 
Amiga-Betriebssystems, repräsentiert durch 
die »layers.library«? Jeder Aufruf der Open- 
Window()-Funktion liefert uns einen Zeiger 
auf den RastPort unseres Fensters. Über den 
RastPort ist es dann möglich, auf den verant¬ 
wortlichen Layer zuzugreifen. Dieser Layer 
veranlaßt die »graphics.library«, jeden Zei¬ 
chenbefehl automatisch und falls notwendig 
zu clippen. Ersetzt man den Layer-Pointer 
probeweise durch null und zeichnet anschlie¬ 
ßend eine Linie, stellt man fest, daß es jetzt 
möglich ist, über die Fenstergrenzen hinaus 
zu zeichnen. Selbstverständlich ist der Layer- 
Pointer wieder auf den ursprünglichen Wert 
zu setzen, bevor wir das Fenster schließen - 
sonst bleiben Speicherleichen übrig. 

Bis heute (Betriebssystem OS-2.0) ist der 
Clipping-Algorithmus noch immer nicht feh¬ 
lerfrei. Bei großen X- bzw. Y-Werten (z.B. 
Draw(RPort.50000,100000)) versagt er und 
verursacht Systemabstürze. 3-D-Clipping 
hingegen ist Betriebssystemfremd und ist 
insofern sowieso zu implementieren. 

Doch bleiben wir zunächst im Zweidimen¬ 
sionalen. Unsere Aufgabe ist es, das Zeich¬ 
nen nur in einem definierten rechteckigen 
Bereich zuzulassen und alle Pixel (Bild¬ 
punkte), die diesen verlassen, nicht abzubil¬ 
den. Clipping innerhalb beliebiger Umrisse 
macht man im Amiga am besten über Mas- 
ken-Bitplanes, die u.a. bei Zeichenoperatio¬ 
nen des Blitters Verwendung finden. 

2-D-Clipping und die 
Begrenzung des Bildschirmfensters 

Wir unterscheiden im 2-D-Raum zwischen 
zwei oft anzutreffenden Clipping-Verfahren: 
□ Clippen beim Plazieren von rechteckigen 
Bildteilen, z.B. mit den Funktionen Rect- 
FillQ, BltBitMapO oderTextQ. 



□ Clippen beim Zeichnen von Linien mit 
z.B. Move() oder Draw(). 

In beiden Fällen soll das Clipping mit 
möglichst wenigen Befehlen, also optimiert, 
erfolgen. Bei einem dreidimensionalen Bal¬ 
lerspiel müssen schließlich Zehntausende sol¬ 
cher Linien gezeichnet werden. Durchdachte 
Algorithmen sind hier entscheidend. 



Bild 2: Dieses Vorgehen führt zum 
falschen Ergebnis, da nur eine Koor¬ 
dinate berücksichtigt bzw. verkürzt 
wird - beide Punkte sind zu beachten 

Das klassische Verfahren für rechteckige 
Bereiche funktioniert über die IF-Abfrage. 
Hier sind hintereinander mehrere Bedingun¬ 
gen zu checken, die feststellen, wo abge¬ 
schnitten wird und wieviel darzustellen ist. 

In der graphics.library finden wir den 
Befehl ClipBlit(). Der Name verrät, wo diese 
Funktion eingesetzt wird: beim Kopieren 
eines rechteckigen Bildausschnitts von einem 
RastPort zum anderen inkl. Clipping. Der 
Nachteil dieser Funktion ist, daß das Zeich¬ 
nen mit dem Elektronenstrahl synchronisiert 
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wird. Das vermeidet zwar einerseits 
V unschönes Flackern, andererseits geht 
M alles sehr langsam. Für Animation 
jedenfalls ist es völlig indiskutabel, und 
W das Flackern bereitet uns beim Double- 
Buffering sowieso keine Kopfschmerzen. 

Doch es gibt noch eine andere Funktion: 
BltBitMapO. An Geschwindigkeit ist diese 
kaum zu übertreffen, zeichnet aber gnadenlos 
über alle Bildschirmbegrenzungen hinaus. 
Die im Listing vorgestellte Routine verbindet 
beides miteinander, indem sie die Koordina¬ 
ten vor dem BltBitMap-Aufruf clippt. 

Der Funktion ClipBltBitMap übergeben 
wir neben den BltBitMap-Parametern zusätz¬ 
lich sw (Sourcewidth, die Breite des Ori¬ 
ginalausschnitts), sh (Sourceheight, die Höhe 
des Originalausschnitts), dw (Displaywidth) 
und dh (Displayheight). Sie repräsentieren 
die Clip-Grenzen. Ansonsten ist sie mit der 
des BltBitMap-Kommandos identisch. 

Zunächst überprüfen wir, ob sx, sy, 
sx+sizex und sy+sizey im erlaubten Bereich 
liegen - man bezeichnet das als Source-Clip- 
ping. Ist das nicht der Fall, stutzen wir sie 
zunächst zurecht. Danach führen wir das 
Ziel-Clipping aus: dx, dy, dx+sizex und 
dy+sizey checken wir wiederum und verklei¬ 
nern eventuell den Zielbereich. Anschließend 
darf gezeichnet werden. 

Die Prozedur besteht aus 14 IF-Abfragen. 
Ohne Source-Clipping reduzieren sie sich auf 
acht. Das ist verschwindend gering gegen¬ 
über dem eigentlichen Blit-Vorgang, der 
Tausende von Bytes verschiebt. Er kann also 
guten Mutes jedesmal angewandt werden. 
Dennoch ist der vorgestellte Befehl um ein 
Vielfaches schneller als ClipBlit(). In Bild 1 
sind die Abfragen grafisch dokumentiert. 

Wer die Übergabe so vieler Parameter bei 
jedem Zeichenbefehl vermeiden möchte, 
kann dies durch globale Variablen erreichen. 
Da sich die Clip-Bereiche dw, dh, sw und sh 
meist nicht verändern, ist das sinnvoll. Ist 
jedoch sicher, daß der original Bildausschnitt 
niemals außerhalb des Bereichs liegt, kann 
vom Source-Clipping abgesehen werden. 

Im Listing finden Sie keine Makros wie 
z.B. MIN(a,b) oder »? :« (bedingte Bewer¬ 
tung). Mit Absicht: Der Compiler generiert 
so besseren Code. Das soll kein Plädoyer für 
überkommenen Programmierstil sein, son¬ 
dern notwendiger Kompromiß beim Schaffen 
zeitkritischen Codes. 

Üblicherweise belegen wir bei BltBitMap 
den Parameter »minTerm« mit OxCO und 
»mask« mit OxFF: so blitten wir alle Bitpla¬ 
nes. »tempA« darf null sein, wenn sich der 
Quell- und Zielbereich nicht überlappen. 
Ansonsten müssen wir einen Zeiger auf einen 
Speicherbereich für eine Bildschirmzeile 
(maximum 128 Byte) angeben. Tun wir das 
nicht, allokiert BltBitMap automatisch einen 
128 Byte großen Speicherbereich, der aller¬ 
dings nicht freigegeben wird. 

Clippen von Linien 

Clippen von Linien ist aufwendiger als das 
von Rechtecken. Es genügt nicht einfach. 


eine X-Koordinate auf Null zu setzen (sofern 
sie kleiner ist), während die zugehörige Y- 
Koordinate unverändert bleibt. Die Linie 
liegt zwar dann nicht mehr außerhalb des 
sichtbaren Bereichs, aber ihre Steigung ist 
falsch (Bild 2). Bei Modifikation einer Koor¬ 
dinate ist die zweite ebenfalls zu ändern. 

Eine hocheffiziente Lösung dieses Pro¬ 
blems lieferten schon in den sechziger Jahren 
Dan Cohen und Ivan Sutherland. Das im 
Anschluß vorgestellte Verfahren bezeichnet 
man daher auch als den Cohen-Sutherland- 
Algorithmus. Dahinter verbirgt sich folgende 
Idee: Man verlängert die Linien gedanklich 
bis über den Bildschirmrand hinaus (gestri¬ 
chelte Linien in Bild 3). Insgesamt sind es 
acht Fortsetzungen, die durch Kombinationen 
von Oben, Unten, Rechts und Links entste¬ 
hen. Im Bild finden Sie alle möglichen. Es 
gibt z.B. Linien, die völlig außerhalb des 
Bildschirms liegen. Von anderen wiederum 
ist mindestens ein Punkt sichtbar, oder sie 
streifen nur den sichtbaren Bereich. Selbst¬ 
verständlich gibt’s auch solche, die vollstän¬ 
dig innerhalb liegen. Ein einziges Durchein¬ 
ander. 

Auf den ersten Blick scheinen die IF- 
Abfragen ins Unermeßliche zu steigen. Wie 
sieht also die Systematik aus, die, auf das 
Notwendigste reduziert, festlegt, wann eine 
Linie ganz oder teilweise gezeichnet oder 
vollständig verworfen wird? 

Zuerst unterziehen wir beide Endpunkte 
einer Prüfung, in welchem Außenbereich 
seine Koordinaten liegen: Oben, Unten, 
Rechts oder Links (O, U, R bzw. L). Für 
jeden Punkt können maximal zwei Bereiche 
zutreffen. Der erste Punkt PI der Linie A in 
Bild 3 liegt in R, P2 in U. Aber auch PI von 
Linie B liegt in R, und P2 in U. Linie B 
jedoch liegt vollständig außerhalb des Bild¬ 
schirms. 

Folgendes läßt sich schon erkennen: Wenn 
sich weder PI noch P2 in 0,U,R, oder L ver¬ 
weilt, muß nicht geclippt werden - die Linie 
befindet sich vollständig innerhalb. Linie C 
demonstriert das. 



Bild 3: So ist es richtig - durch ge¬ 
dankliche Verlängerung der Linien 
und Aufteilung in Bereiche ist das 2- 
D-Clippen für uns kein Problem 


Außerdem gilt: Haben sowohl PI als auch 
P2 mindestens eine gleiche Seite (beide z.B. 
U (Linie D)), ist es nicht notwendig, diese zu 
zeichnen. Die Funktion CheckXY() prüft die 
Kantenlagen der Linien und setzt für jede der 
vier Bereiche O, U, R, bzw. L ein Bit in der 
Variablen Kl bzw. K2. Eine logische Und- 
Verknüpfung prüft alle Linien auf die Lage 
außerhalb des Bildes. 

Treffen beide Bedingungen nicht zu, muß 
Kante für Kante überprüft und verkürzt wer- 



Würfel nahezu vollständig sichtbar - 
lediglich die vorderste Ecke taucht in 
die imaginäre Clip-Ebene ein 

den. Nehmen wir an, ein Punkt liegt im R- 
Bereich (X >= XMax). Wir wissen, daß dann 
X auf XMax-1 zu setzen ist. Die Y-Strecke 
ist dann proportional der noch sichtbaren X- 
Strecke zu kürzen. Das geschieht mit: 
y=y+(XMin-x)*dy/dx 

wobei dy die Differenz der beiden Y-Koordi- 
naten und dx die der beiden X-Koordinaten 
repräsentiert. Eine Division durch null ist 
unmöglich, da in diesem Fall (dx oder dy 
gleich null) beide Punkte auf derselben Seite 
liegen und die erste Abfrage 
if((Kl & K2)1=0) 
diese Eventualität abfängt. 

y kann nach dieser Berechnung kleiner als 
YMin oder größer bzw. gleich YMax sein, 
wenn z.B. die Linie von R nach U gezeichnet 
wird und die untere rechte Ecke des Bildbe¬ 
reichs nicht schneidet. Es genügt also die 
Abfrage: 

if(y<YMin II y>YMax) 

/* Linie kreuzt außerhalb die Felder */ 
return(FALSE)'; 

Das ist das ganze Geheimnis. Alle anderen 
Fallunterscheidungen sind Spiegelungen und 
Symmetrien dieser zwei Zeilen. Insgesamt 
sind vier Fallunterscheidungen pro X- bzw. 
Y-Koordinate nötig. Man muß sich vor 
Augen halten, daß von den vielen Programm¬ 
zeilen in den meisten Fällen nur ganz wenige 
durchlaufen werden - bei Linien, die über 
den Rand des Bildschirms hinaus gezeichnet 
werden. Linien, bei denen das Clippen 
unnötig ist, handelt das Programm mit drei 
IF-Abfragen ab. Linien, die sowohl in X- als 
auch Y-Richtung zu beschneiden sind, 
benötigen im ungünstigsten Fall sieben Fall¬ 
unterscheidungen und vier X/Y-Berechnun- 
gen (zzgl. der obligatorischen zwei bis vier 
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der Funktion CheckXYO pro Punkt). Schnel¬ 
ler geht's also kaum - wenigstens nicht auf 
algorithmischem Weg. Der Quelltext des 2- 
D-Clippings besteht aus den Funktionen 
CheckXYO, MoveClipO und DrawClip(). 
MoveClip und DrawClip lassen sich wie die 
Funktionen Move() bzw. Draw() der gra- 
phics.library verwenden. Auf den RastPort 
wird via globaler Variable zugegriffen. Die 
Variablen xl, yl, dx und dy sind vom Typ 
LONG, da sonst Überläufe Vorkommen. 

3-D-Clipping 

Warum 3-D-Clipping, wenn 2-D-Clipping 
bereits dafür sorgt, daß sich niemals Linien 
außerhalb des Bildschirms oder Fensters 
zeichnen lassen? Denken wir uns wieder 
einen dreidimensionalen Würfel als Drahtgit¬ 
termodell. Jeder Eckpunkt des Würfels ist als 
Koordinate X,Y,Z gegeben. Die Formel für 
die Projektion auf den Bildschirm: 

X'=PRF*X/(Z+PRF); 

Y'=PRF*Y/(Z+PRF); 

Z ist der Abstand vom Betrachter und PRF 
ein Projektionsfaktor, der den Grad der Zen¬ 


tralperspektive regelt. Je größer PRF, umso 
flacher wirkt die Perspektive. Man erkennt 
sofort, daß ein Objekt mit dem Abstand 
0+PRF eine Division durch null zur Folge 
hätte, denn ein Objekt, das genau im Brenn¬ 
punkt der Kamera (oder des Betrachters) 
liegt, wäre unendlich groß zu projizieren. Ein 
negativer Z-Wert bedeutet, daß sich das 
Objekt hinter der Kamera aufhält. In diesem 
Fall liefert die Projektion trotzdem positive 
X'/Y'-Werte, obwohl ein Objekt hinter der 
Kamera mit Sicherheit nicht zu sehen ist. 3- 
D-Clipping ist also nichts anderes als das 
Abschneiden aller Linien an einer Ebene, die 
senkrecht zur Blickrichtung irgendwo vor (im 
positiven Bereich) der Kamera liegt. Dieser 
Abstand ist wählbar und im folgenden mit 
CE (Clip-Ebene) bezeichnet. 

Bild 4 zeigt einen schräg von vom betrach¬ 
teten Würfel bei groß gewähltem CE. Man 
erkennt, daß 3-D-Clipping nur für nahe gele¬ 
gene, sehr groß projizierte Objekte notwen¬ 
dig ist. 

Betrachten wir eine Linie, deren Anfang 
vor, das Ende hinter der Clip-Ebene liegt. Die 


Koordinaten des Punkts vor der Clip-Ebene 
sind zu transformieren. Z erhält den CE zuge¬ 
ordneten Wert, X bzw. Y müssen sich dem¬ 
zufolge proportional zum Streckenverhältnis 
der noch sichtbaren Linie verkürzen - jetzt 
allerdings im Raum und nicht in der Bild¬ 
ebene, wie beim 2-D-Clipping demonstriert. 
Die Vorgehens weise ist dennoch äquivalent. 
Bild 5 dokumentiert die die Clip-Ebene 
schneidende Linie und den daraus entstehen¬ 
den Punkt mit den Koordinaten XC, YC und 
ZC. Er liegt genau auf der Clip-Ebene (ZC 
gleich CE). 

Das Prinzip des 3-D-Clippings sollte jetzt 
klar sein. Es exisitiert jedoch nicht nur das 
hier gezeigte Verfahren, das zuerst im Raum 
und anschließend jede Koordinate nochmals 
in der Ebene isoliert: Es stehen Verfahren zur 
Verfügung, die geschickt im Raum clippen, 
das einen anschließenden 2-D-Algorithmus 
überflüssig macht. 

Zumindest theoretisch ist sichergestellt, 
daß die projizierten Koordinaten niemals 
außerhalb des Bildschirms liegen. Das Ver¬ 
fahren basiert nun darauf, nicht nur alle 


1 

/* 

70 

if(sizey > sh-sy) 

2 

* Autor: Bernhard Emese 

71 

sizey=sh-sy; 

3 

* Demo für 2d 3d Clipping Algorithmus: Rechteckiges Source- 

72 


4 

* und Destinationclipping nach Cohen-Sutherland für Aztec-C 

73 

/* Destination-Clipping: Das zu zeichnende Recteck kann in 

5 

* Version 5.2a. Compileraufruf: 

74 

* allen Richtungen zu groß sein. Die Vorgehensweise ist 

6 

* cc cliptest.c -ps -f8 -c2 

75 

* zu dem des Source-Clippings identisch */ 

7 

* Wer über keinen Floatingpoint-Prozessor und keinen 

76 


8 

* MC68020/30-Prozessor verfügt, muß die Include-Datei 

77 

if(dx>=dw || dy>=dh) 

9 

* <libraries/mathffp.h> einbinden und übersetzen mit 

78 

return; // Zeichenbereich liegt komplett außerhalb 

10 

* cc cliptest.c -ps -ff 

79 


11 

*/ 

80 

if(dx<0) { 

12 

#include <functions.h> 

81 

/* Wenn das Ziel zu weit links leigt, dann dx=0 setzen und 

13 

ttinclude <stdlib.h> 

82 

* sizex verkleinern */ 

14 

#include <stdio.h> 

83 

sizex+=dx; 

15 

#include <exec/types.h> 

84 

sx-=dx; // sx wird größer 

16 

Sinclude <intuition/intuition.h> 

85 

dx=0; //am linken Rand wird geclippt 

17 

#include cintuition/screens.h> 

86 

} 

18 


87 

if(dy<0) ( 

19 

#define WIDTH 640 

88 

sizey+=dy; // sizey wird kleiner 

20 

*define HEIGHT 512 // 512 für Interlace, sonst 256 

89 

sy-=dy; // sy wird größer 

21 

#define XMin 20 // erste erlaubte Koordinate links 

90 

dy=0; //am oberen Rand wird geclippt 

22 

#define XMax (WIDTH-20) // letzte erlaubte Koordinate rechts 

91 

} 

23 

#define YMin 20 // erste erlaubte Koordinate oben 

92 


24 

#define YMax (HEIGHT-20) // letzte erlaubte Koordinate unten 

93 

/* Ragt der Ausschnitt noch über den linken und/oder unteren 

25 

fcdefine OBEN 0x01 // Flags für 2-D-Clipping 

94 

* Bildschirmrand ? */ 

26 

#define UNTEN 0x02 

95 


27 

#define LINKS 0x04 

96 

if (sizex > dw-dx) 

28 

#define RECHTS 0x08 

97 

sizex=dw-dx; // sizex verkleinern 

29 

#define FALSE 0 

98 


30 

#define TRUE 1 

99 

if(sizey > dh-dy) 

31 

#define NULL 0L 

100 

sizey=dh-dy; II sizey verkleinern 

32 


101 


33 

struct RastPort *RPort; 

102 

1* Jetzt kann durch Abschneiden an allen Ecken und Enden von 

34 

LONG xl,yl,x2,y2; // Anfangs- und Endkoordinate der zu 

103 

* sizex und sizey evtl, nichts mehr übrig sein *1 

35 

// zeichnenden 2d Linie 

104 


36 

SHORT kl,k2; // Kanten-Flags für Anfangs und Endpunkt 

105 

if(sizex>0 && sizey>0) 

37 


106 

Blt BitMap(SrcMap,sx,sy,DstMap,dx,dy, 

38: 

void ClipBltBitMap ( struct BitMap *SrcMap,SHORT sx. 

107 

sizex,sizey,OxcOL,OxffL,NULL); 

39: 

SHORT sy,struct BitMap *DstMap, 

108 

} 

40: 

SHORT dx,SHORT dy,SHORT sizex,SHORT sizey. 

109 


41: 

SHORT minTerm,SHORT mask, SHORT *tempA, 

110: SHORT CheckXY (LONG x,LONG y) { 

42: 

SHORT sw,SHORT sh,SHORT dw,SHORT dh) 

111 

SHORT k; 

43 

{ 

112 


44 

/* Source-Clipping -- das auszuschneidende Rechteck kann in 

113 

if(y<YMin) // Liegt Y Koordinate unter Minimum ? 

45 

* allen Richtungen zu groß sein */ 

114 

k=UNTEN; 

46 

if(sx>=sw II sy>=sh) 

115 

eise if(y>YMax) // Wenn nicht, kann sie nur Oben liegen 

47 

return; // gewünschter Ausschnitt existiert nicht 

116 

k=OBEN; 

48 


117 

eise 

49 

if(sx<0) { 

118 

k=0; // Wenn nicht Oben, dann im Bild 

50 

/* wenn sx kleiner 0, dann sx=0 setzen und sizex 

119 


51 

* verkleinern */ 

120 

if(x<XMin) // Liegt X-Koordinate unter Minimum ? 

52 

sizex+=sx; // sizex wird kleiner, da sx negativ 

121 

return(k1=LINKS); // Return, da X nicht gleichzeitig 

53 

dx-=sx; // dx entsprechend nach rechts verschieben 

122 

// Links und Rechts liegen kann 

54 

sx=0; 

123 

eise if(x>XMax) II Wenn nicht, dann Rechts 

55 

) 

124 

return(k1=RECHTS); 

56 

if(sy<0) { 

125 

return(k); // Oder in Bildmitte 

57 

/* Y wird genau wie X behandelt: sy=0 setzen und sizey 

126 

} 

58 

* verkleinern */ 

127 


59 

sizey+=sy; // sizey wird kleiner, da sy negativ 

128: void MoveClip (LONG x,LONG y) { 

60 

dy-=sy; // dy entsprechend nach unten verschieben 

129 

// setze Flags je nach Lage des Punkts in 0, U, R, oder L 

61 

sy=0 ; 

130 

kl=CheckXY(xl=x,yl=y); 

62 

} 

131 

} 

63 


132 


64 

/* Jetzt kann der Ausschnitt nur noch rechts und/oder unten 

133 

SHORT DrawClip(LONG x2c,LONG y2c) { 

65 

* über den Quellbereich hinausragen */ 

134 

LONG xlc,ylc,dx,dy; 

66 


135 

SHORT k; 

67 

if(sizex > sw-sx) 

136 


68 

sizex=sw-sx; 

137 

k2=CheckXY(x2=x2c,y2=y2c); // setze Flags 

69 


138 
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xlc=xl; ylc=yl; k=kl; 

/* xlc,ylc mit letzter nicht-geclippter Koordinate 
* xl,yl laden */ 

xl=x2c; yl=y2c; kl=k2; 

// ungeclippte neue Koordinate für nächstes Draw abspeichern 

if ((k & k2)!=0) 

return(FALSE); // Beide Punkte liegen auf gleicher Seite 

// außerhalb 

dx=x2c-xlc; 

dy=y2c-ylc; 

if(k) { // Liegt PI irgendwo außerhalb ? 

if(k & LINKS) { // wenn links, dann 

ylc+=(XMin-xlc)*dy/dx; // dx kann hier nie 0 sein 
if(ylc<YMin II yloYMax) 

return(FALSE); // Linie kreuzt außerhalb die Felder 

xlc=XMin; 

} eise if(k & RECHTS) { 
ylc«-= (XMax-xlc) *dy/dx; 
if (ylc<YMin II yloYMax) 

return(FALSE); // Linie kreuzt außerhalb die Felder 

xlc=XMax; 

} 

if(k & UNTEN) ( 

xlc+=(YMin-ylc)*dx/dy; // dy kann hier nie 0 sein 

if(xlc<XMin II xloXMax) 

return(FALSE); // Linie kreuzt außerhalb die Felder 

ylc=YMin,* 

) eise if(k & OBEN) { 
xlc+=(YMax-ylc)*dx/dy; 


if(xlc<XMin II xloXMax) 
return(FALSE) ,• // Linie 

ylc=YMax; 


if(k2) { // liegt 

if(k2 & LINKS) { 
y2c+=(XMin-x2c)*dy/dx; // 
if(y2c<YMin II y2c>YMax) 
return(FALSE); // Linie 

x2c=XMin; 

) eise if (k2 Sc RECHTS) { 
y2c+=(XMax-x2c)*dy/dx; 
if(y2c<YMin II y2c>YMax) 
return(FALSE); // Linie 

x2c=XMax; 

} 

if (k2 Sc UNTEN) { 

x2c+=(YMin-y2c)*dx/dy; // 

if(x2c<XMin II x2c>XMax) 
return(FALSE); // Linie 

y2c=YMin; 

} eise if(k2 & OBEN) { 

x2c+=(YMax-y2c)*dx/dy; 
if(x2c<XMin II x2c>XMax) 
return(FALSE); // Linie 

y2c=YMax; 

} 


kreuzt außerhalb die Felder 


P2 irgendwo außerhalb 
dx kann hier nie 0 sein 


kreuzt außerhalb die Felder 


kreuzt außerhalb die Felder 


dy kann hier nie 0 sein *I 
kreuzt außerhalb die Felder 


kreuzt außerhalb die Felder 


Move(RPort,xlc,ylc); 
Draw(RPort,x2c,y2c); 
return(TRUE); 


Linien gegen die senkrecht zur Blickrichtung 
liegende Clip-Ebene zu überprüfen, sondern 
zusätzlich an den vier Flächen eines nach 
hinten in die Unendlichkeit reichenden Pyra¬ 
midenstumpfs. Stellt man sich einen Blick in 
den Raum vor, der bei einer 3-D-Zeichnung 
auf dem Bildschirm einsehbar ist, ist das 
genau der Inhalt jenes Pyramidenstumpfs und 
folglich klar, daß ein Raum-Clipping, wel¬ 
ches Objekte nur in diesem zuläßt, auf das 
nachträgliche 2-D-Clipping verzichten kann. 

Das aber ist Theorie. In der Praxis kämpft 
man bei dieser Projektion mit Ungenauigkei¬ 
ten der Fließkomma-Arithmetik: ein Punkt 
Ungenauigkeit führt dazu, daß über den sicht¬ 
baren Bereich hinausgezeichnet wird und 
bedeutet oftmals den Systemabsturz. 2-D- 
Clipping hingegen ist ein auf Ganzzahlen 
operierendes Verfahren und schließt eben¬ 
diese Fehler aus. Darüber hinaus ist die 
Berechnung des vollständigen 3-D-Clippings 
wesentlich zeitintensiver und rechenaufwen¬ 
diger als das hier vorgestellte, da einer Ebe¬ 
nenberechnung mit 2-D-Clipping fünf 3-D- 
Berechnungen (vordere Clip-Ebene und vier 
Pyramidenseiten) gegenüberstehen. 

Unser Programm prüft also jede Linie 
gegen die Clip-Ebene und schneidet sie gege¬ 
benenfalls ab. Ab einer definierten Stelle 
enden die Linien irgendwo im Raum, als 
rückte man mit einer Zange dem Drahtgitter¬ 
modell zu Leibe und zwickte einige Drähte 
ab. Wählt man also die Clip-Ebene nahe dem 
Betrachter, sind die Drahtenden niemals 
sichtbar. 

Unser Listing demonstriert das auf an¬ 
schauliche Weise. Der Würfel wird nach 
rechts, links, oben und unten bewegt, dann 
vor und zurück, wobei Teile des Drahtgitters 
aus dem Bild verschwinden oder in die Clip- 
Ebene eintauchen. Das Resultat des Clip- 
pings ist sichtbar und überprüfbar. 

Die hier vorgestellte Mini-3-D-Library ist 
bereits dazu ausgelegt, Objekte im Raum zu 
drehen, denn auch bei einer Drehung des 
Würfels ohne Verschiebung des Betrachter¬ 
standpunkts ist es wahrscheinlich, daß der 
Würfel bereits die Clip-Ebene schneidet, 


selbst wenn er es in seiner Ruhelage noch 
nicht tut. Deshalb gehen wir kurz auf die vom 
Programm verwendete Rotationsmatrix ein. 

Sie ist ein Schlüssel für viele 3-D-Trans- 
formationen, nicht nur für Drehungen. Die 
vier Parameter für jede Koordinate besitzen 
eine Fülle von Kombinationen, die hier zu 
erörtern unseren Rahmen sprengen würde. Es 
lassen sich jedoch mit einer solchen Matrix 
Verschiebungen, Verzerrungen, Skalierun¬ 
gen, asymmetrische Drehungen etc. vorneh¬ 
men, vorausgesetzt, man hat die Werte vor¬ 
her sinnvoll besetzt. Die im Programm vorge¬ 
gebene ZeroMatrix ist übrigens das neutrale 
Element der Matrizenmultiplikation, führt 
also keine Transformation aus. 

In unserem Beispiel besetzt die Funktion 
Rotate() die Matrix nur mit Werten für die 
drei Drehungen im Raum. Man gibt drei 
Winkel vor, um die jeder Eckpunkt des Wür¬ 
fels rotiert werden soll. Hat man einmal die 
Matrix mit gültigen Werten besetzt, wird sie 
für jeden Eckpunkt berechnet. Die Vorbe¬ 
rechnung ist nicht ganz einfach und insofern 
wichtig, da die Transformationsfunktionen 
ansonsten für alle acht Eckpunkte mit Hilfe 
der trigonometrischen Funktionen Sinus und 
Cosinus berechnet werden müßten. Für einen 
Würfel entspricht die Ersparnis also 8:1, bei 
komplexeren Objekten sogar noch günstiger. 

Ideal ist die Matrix dann, wenn sich nicht 
das Objekt, sondern der Standpunkt des Be¬ 
trachters ändert (z.B. ein Kameraschwenk), 
da in diesem Fall die Koordinaten aller 
Objekte zu berechnen sind. Unser Listing 
enthält allerdings keine Kameratransforma¬ 
tion, es »schaut« stur in die Z-Richtung. 

Die einzige Kameratransformation ist die 
freie Wahl des Betrachterstandpunkts mit 
BX, BY und BZ. Die Wirkung eines größe¬ 
ren Abstands durch die verkleinerte Darstel¬ 
lung des Objekts erzielt der Betrachter 
dadurch, indem sein Wert von jedem Punkt 
subtrahiert wird 

Mit dem beschriebenen Verfahren lassen 
sich alle linienorientierten Objekte ordnungs¬ 
gemäß und in der Praxis ausreichend effizient 
clippen. Dennoch sind die Anforderungen 


moderner Computergrafik keineswegs er¬ 
schöpf. Zu den am häufigsten verlangten 
Verfahren zählt das Polygon-Clipping. Poly¬ 
gone (geschlossene Linienzüge), die über den 
2-D-Bereich hinausragen, können zwar Linie 
für Linie gekappt werden - das Ergebnis ist 
aber kein geschlossenes Polygon mehr. 

Möchte man ein so verstümmeltes Polygon 
mit einer Farbe füllen - Sie können sich vor¬ 
stellen, was passiert: Da die Linien zum Bild¬ 
schirmrand nicht mehr geschlossen sind, 
»läuft« die Farbe sozusagen aus. Doch auch 
für dieses Problem gibt's Lösungen. Diese 
gehen nach dem Prinzip vor, ein aus wenig 
Punkten bestehendes Polygon mit mehr 
Punkten darzustellen. Der Vorteil: die Kan¬ 
tenlänge der Linien wird verkürzt. 

Außerdem ist eine zusätzliche Fläche ein¬ 
zuführen, falls es sich um einen massiven 



Bild 5: Auch auf dreidimensionale 
Objekten läßt sich der zweidimensio¬ 
nale Clipping-Algorithmus anwenden 

Würfel (kein Hohlwürfel) handelt, die den 
Blick in den Würfelinnenraum verdeckt. 
Flächen- und kantenorientiertes 3-D-Zeich- 
nen von Objekten ist nicht immer trivial. 

Das hier abgedruckte Listing finden Sie 
auch auf der Diskette zum Heft (Seite 114). 
Das erspart Tipparbeit und unnötige Fehler¬ 
suche. rz 
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GRUNDLAGEN 


205 


317 

o = M[3][0]*COS + ME 31[2]*MSIN; 

206 

// Anfangs- und Endpunkte der 3-D-Linie 

318 

MC3][2] = M[3][0]*SLN - M[3]12)*COS; 

207 

LONG X1,Y1,Z1,X2,Y2,Z2; 

319 

M(3] [0] = o; 

208 

LONG PRF; 

320 


209 

SHORT CE; // Abstand der ClipEbene vom Brennpunkt 

321 

SIN = sin(C=C*PI/180); MSIN = -SIN; 

210 

SHORT BX.BY.BZ; // Betrachterstandpunkt (Kamera) 

322 

COS = cos(C); 

211 


323 

o = M[0][0]*COS + M[0][1]*SIN; 

212 

FLOAT ZeroMatrix[4][4] = { 

324 

M[0]11] = M(0][0]*MSIN + M[0][1]*COS; 

213 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

325 

M(0] 10] = o; 

214 

FLOAT Mat rix 14][4]; 

326 

o = M[1][0]*COS + M[1]11]*SIN; 

215 

327 

Mtllll] = MI1]I0!*MSIN + MI1]11]*COS; 

216 

#def ine CONVERTX (x, z) (PRF* (X) / ( ( 2 ) +PRF) +WIDTH/2) 

328 

M[1]10] = o; 

217 

#define CONVERTY(y,z) (PRF*(y)/((z)+ PRF)+HEIGHT/2) 

329 

o = M 12]I0]*COS + M12] [1]*SIN; 

218 

330 

M12][1] = MI2]10]*MSIN + M[2]{l]*COS; 

219 

void Transform3d (FLOAT M[4)[4],LONG *X,L0NG *Y,LONG *Z) { 

331 

MI2]10] = o; 

220 

LONG XU,YU,ZU; 

332 

o = MI3][0]*COS + M13][1]*SIN; 

221 


333 

MI3JI1] = MI3]10]*MSIN + M[3][1]*COS; 

222 

XU=*X; // zu drehende verschiebende Koordinate 

334 

MI3] 10] = o; 

223 

// Zwischenspeichern 

335 

) 

224 

YU=*Y; 

336 


225 

ZU=*Z; 

337 

struct Library ‘IntuitionBase,*GfxBase; 

226 

338 

struct Window *Window; 

227 

/* beliebige Tranformation ausführen */ 

339 

static struct NewWindow nw = { 

228 

*X=M{0][0]*XU+M(1][0]*YU+M[2](0]*ZU+M(3][0]; 

340 

0,0, WIDTH,HEIGHT, 0,1, 0, ACTIVATE, NULL, NULL, 

229 

*Y=M[0][1]*XU+M[1][1]*YU+M[2] ll]*ZU+M(3][1]; 

341 

(UBYTE *)"2d 3d Clipping", NULL, NULL, 0,0,WIDTH,HEIGHT, 

230 

342 

WBENCHSCREEN, 

231 

/* die Art der Drehung, Verschiebung etc. ist vom 

343 

); 

232 

* Inhalt der Matrix abhängig */ 

344 


233 

*Z=M[0](2]*XU+M(1][2]*YU+M[2][2]*ZU+M[3][2]; 

} 

345 

/* 

234 

346 

* Zeichnet alle Kanten eines Drahtgitterwürfels und 

235 


347 

* löscht vorher den Hintergrund 

236 

void Move3dClip (LONG X,LONG Y,LONG Z) { 

348 

*/ 

237 

Transform3d(Matrix,&X,&Y,&Z) ; 

349: 

void Cube () { 

238 


350 

SetAPen(RPort.O) ; 

239 

X1=X-BX; // Betrachterstandpunkt von Koordinate abziehen 

351 

RectFill(RPort,XMin,YMin,XMax,YMax) ; 

240 

Yl-Y-BY; 

352 

SetAPen(RPort,1) ; 

241 

Zl=Z-B2f; 

} 

353 

Move3dClip(-250,+250,-250) ; Draw3dClip(+250,+250,-250) ; 

242 

354 

Draw3dClip(+250,-250,-250) ; Draw3dClip ( -250, - 250,-250) ; 

243 


355 

Draw3dClip(-250,+250,-250) ; Draw3dClip(-250,+250.+250) ; 

244 

void Draw3dclip (LONG X,L0NG Y,LONG Z) { 

356 

Draw3dClip(+250,+250,+250) ; Draw3dClip < +250,-250,+250) ; 

245 

FLOAT RQ; 

357 

Draw3dClip ( -250,-250,+250) ; Draw3dClip ( -250,+250,+250) ; 

246 

358 

Move3dClip(+250,+250,-250) ; Draw3dClip(+250,+250,+250) ; 

247 

Transform3d(Matrix,&X,&Y, &Z) ; 

359 

Move3dClip(+250,-250,-250) ; Draw3dClip ( +250,-250,+250) ; 

248 

360 

Move3dClip(-250,-250,-250) ; Draw3dClip(-250,-250,+250) ; 

249 

X=X-BX; // Betrachterstandpunkt von Koordinate abziehen 

361 

Delay (2) ; 

250 

Y=Y-BY; 

362 

} 

251 

Z=Z-BZ; 

363 


252 


364 

Movement ( SHORT i ) { 

253 

if(Z1>=CE) { // alte Koordinate hinter Clipebene ? 

365 

if(i<100) return(-i); // fährt zuerst nach links 

254 

MoveClip(CONVERTX(XI,ZI),CONVERTY(Y1,ZI )); 

366 

if(i<300) return(-200+i) ; // dann nach rechts 

255 

if(Z>=CE) 

367 

return(400-i> ; // dann wieder auf den Anfangspunkt 

256 

// neue Koordinate auch: kein Clipping erforderlich 

368 

} 

257 

DrawClip(CONVERTX(X,Z),CONVERTY ( Y,Z )); 

369 


258 

eise ( 

370 

main() { 

259 

// Zielkoordinate clippen, Streckenverhältnis berechnen 

371 

SHORT i, j; 

260 

RQ=(FLOAT)(CE-Zl )/( Z-Zl ); 

372 

IntuitionBase=OpenLibrary { (UBYTE *)" intuition.1ibrary " ,NULL) ; 

261 

Xl + = (X-Xl ) *RQ; //X proportional verkürzen 

373 

262 

Yl+=(Y-Yl ) *RQ; // Y proportional verkürzen 

374 

GfxBase=OpenLibrary ( (UBYTE *) "graphics.library",NULL) ; 

263 

Z1=CE; // Z auf Clipebene setzen 

375 


264 

DrawClip(CONVERTX(XI,ZI)»CONVERTY(Y1,Z1)); // Zeichnen 

} 

376 

Window=OpenWindow(&nw); // öffnet Workbench-Fenster 

265 

377 


266 

) eise // alte Koordinate vor Clipebene 

378 

RPort=Window->RPort; 

267 

if(Z>=CE) ( // neue Koordinate hinter Clipebene --> clippen 

379 

SetAPen(RPor t,2); 

268 

RQ=(FLOAT)(CE-Zl)/(Z-Zl); 

380 

269 

Xl + = (X-Xl)*RQ; 

381 

// Zeichnet eine Umrahmung, die nicht überschritten wird. 

270 

Yl + =(Y-Yl)*RQ; 

382 

271 

Z1=CE; 

383 

Move(RPort,XMin-1,YMin-1); 

272 

MoveClip(CONVERTX(XI,ZI),CONVERTY(Yl,ZI)); 

384 

Draw(RPort,XMax+1,YMin-1); 

273 

DrawClip(CONVERTX(X,Z) ,CONVERTY(Y,Z)); 

} 

385 

Draw(RPort,XMax+1,YMax+1); 

274 

386 

Draw(RPort,XMin-1,YMax+1); 

275 

X1=X; // neuen Punkt ungeclippt für nächstes Draw3d speichern 

387 

Draw(RPort,XMin-1,YMin-1); 

276 

Y1=Y; 

388 


277 

Z1=Z; 

} 

389 

PRF=1000; // Werte für 3d Clipping 

278 

390 

CE= 740; II Clipebene ist 10 Einheiten vor dem Objekt 

279 


391 

BZ=-1000; // Betrachter ist 1000 Einheiten entfernt 

280 

#ifndef PI 

392 


281 

#define PI ((FLOAT) 3.141592653589793) 

393 

for(i=0;i<=400;i+=4) { 

282 

»endif 

394 

II Würfeldrehungen in X,Y,Z 

283 


395 

Rotate(Matrix,Movement(i),Movement(i),Movement(i)); 

284: void Rotate(FLOAT M[4 ] [4],FLOAT A,FLOAT B,FLOAT C) 

396 

Cube(); 

285 

: { 

397 

} 

286 

; FLOAT MSIN,SIN,COS,o; 

398 

Delay(50); 

287 


399 


288 

: movmem((char *)ZeroMatrix, 

400 

m 

+ 

o 

o 

II 

V 

o 

u 

o 

289 

: (char *)Matrix,(int)4*4*sizeof(FLOAT)); 

401 

: BX=Movement(i)* 10; 

290 

402 

: // Würfel rollt nach rechts und links 

291 

: SIN = sin(A=A*PI/180); MSIN = -SIN; 

403 

: Rotate(Matrix,0,0,Movement(i)); 

292 

: COS = COS (A) ; 

404 

: Cube(); 

293 

: O = M[0][1]*COS + MIO](2]*SIN; 

405 

: ) 

294 

: M[0][2] = M[0][1]*MSIN + M[0][2]*COS; 

406 

: Delay(50); 

295 

: M[0][1] = o; 

407 

! for(i=0;i<=400;i+=4) { 

296 

: o = M{1][1]*COS * M[1)[2]*SIN; 

408 

297 

: M[1][2] = M[1] t1]*MSIN + M[l][2]*COS; 

409 

: BY=Movement(i)*10; 

298 

: M (1] 11] = o; 

410 

: II Würfel rollt nach oben und unten 

299 

: o = M[2] [1]*COS + M12] [2]*SIN; 

411 

: Rotate(Matrix,-Movement(i),0,0); 

300 

: M[2][2] = M[2][1]*MSIN + M(2][2]*COS; 

412 

: Cube(); 

301 

: M[2] [1] = o; 

413 

: ) 

302 

: o = M[3][1]*COS + M[3][2]*SIN; 

414 

: Delay(50); 

303 

: M[3] [2] = M[3] [1]*MSIN + M T 3] [2]*COS; 

415 


304 

; M[3]11] = o; 

416 

: for(i=0;i<=400;i+=4) { 

305 

417 

: 3Z=Movement(i)*10-1000; 

306 

SIN = sin(B=B*PI/180); MSIN = -SIN; 

418 

: // Würfel rollt nach vorn und hinten 

307 

: COS = cos(B); 

419 

: Rotate(Matrix,-Movement(i),0,0); 

308 

: o = M(0][0]*COS + M[0][2]*MSIN; 

420 

: Cube(); 

309 

: M(0][2] = M[Q]10]*SIN + M[0][2]*COS; 

421 

: ) 

310 

: MIO][0] = o; 

422 

: Delay(50); 

311 

312 

313 

; o = M[1][0]*C0S + M[1][2]*MSIN; 

: M[l](2] = M[l][0]*SIN + M(l][2]*COS; 

: M [ 1 ] [0] = o; 

423 

424 

425 

»Clipping.c«: Das Listing 

: CloseWindow (Window); rr ? . ^ 

CloseLibrary (GfxBase); deiTlOnStiert das 2- Ulld-O- 

314 

315 

: o = M{2][0]*COS * M[2][2]*MSIN; 

: M[2][2] = M[2][0]*SIN + M[2][2]*COS; 

426 

427 

: CloseLibrary (IntuitionBase); D.Clipping Und läßt Sich 

316 

; M[2][0] = o; 

428 

weiter ausbauen 
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GRUNDLAGEN 


Lichtgriffel am Amiga 

Eierlegende 

Wollmilchsau 


Der Light-Pen (deutsch: Licht¬ 
griffel) findet mit Abstand am 
wenigsten Verwendung am Game¬ 
port des Amiga. Das hat seinen 
Grund: Das Betriebssystem ist 
nämlich ein Gegner des Light- 
Pens und man muß es erst über¬ 
listen. Warum das so ist und wie 
man es macht, zeigen wir hier. 

von Bernhard Emese 

D en Amiga-Entwicklern sagt man nach, 
sie hätten eine »Eierlegende Woll¬ 
milchsau« entworfen. Jedenfalls 
haben sie versucht, einen »Joyballpaddelnden 
AnalogPotentioTrackStick« oder eine »Licht- 
blitzgriffelnde Rollmichmaus« in die Game¬ 
ports einzuhängen. Tatsächlich muß man 
ihnen Respekt zollen. Was man alles unge¬ 
niert dort vorne in die neunpoligen Game- 
port-Buchsen des Amiga 'reinstecken kann, 
ohne daß Rauchwolken einen Racheakt des 
Computers anzeigen, ist schon erstaunlich. 

Die Pins sind auf raffinierte Weise gemul- 
tiplext, abgeblockt, gepull-upped und gewis¬ 
sermaßen ineinander verschachtelt, so daß 
sich an jeden Gameport vier grundsätzlich 
verschiedene Peripheriegeräte anschließen 
lassen: Maus, Joystick, Proportional-Control- 
ler und Light-Pen (letzterer ist immerhin nur 
an einem Gameport anschließbar). Die Soft¬ 
ware kann beide Gameports auf unterschied¬ 
liche Weise abfragen: Einmal als Mouse-, als 
Joystick-Port und als Proportional-Port, oder 
eben als Light-Pen-Port. Entgegen der Doku¬ 
mentation im Hardware-Reference-Manual 



Bild 2: Die Register VHPOS und 
VPOS des Custom-Chips Agnus - sie 
werden vom Amiga permanent inkre- 
mentiert (erhöht) 


[1] ist der Lichtgriffel nur an den zweiten 
Port des Amiga 2000 anschließbar. Die Pin- 
Belegung des 9poligen D-SUB-Steckers als 
Light-Pen-Port finden Sie in Bild 1. 

Man erkennt, daß nur wenige Signale 
benötigt werden. Der Schalter, der in der 
Lichtgriffelspitze untergebracht ist, wird laut 
Dokumentation auf Pin 5 abgefragt. Man 
kann ohne weiteres einen Lichtgriffel des C- 
64 an den Amiga anschließen, den man über¬ 
all preisgünstig erstehen kann. Der Schalter 
dieses Light-Pens allerdings ist über Pin 3 
(Joystick Signal Links) abzulesen. 

Erstaunlich, wie leicht das Skizzieren mit 
einem Lichtgriffel fällt, z.B. beim Zeichnen 
eines Kreises. Mit der Maus hat man ja schon 
Mühe, den Linienanfang genau zu treffen. 
Man müßte allerdings über einen fast waage¬ 
recht in den Schreibtisch eingelassenen fla¬ 
chen Monitor verfügen, um längeres Arbeiten 
mit dem Lichtgriffel zu ermöglichen. Zudem 
ist es mit der Auflösung und Pixelgenauigkeit 
nicht weit her. Horizontal beträgt die Auflö¬ 
sung nur 160 Pixel, unabhängig vom einge¬ 
stellten Bildschirmmodus. Vertikal sind es 
immerhin so viele, wie Rasterzeilen existie¬ 
ren - im PAL-Interlace-Modus also 512. Mit 
Flickerfixer funktioniert er überhaupt nicht. 

Das abgedruckte Programm ist der Über¬ 
schaubarkeit wegen nur für einen Non-Inter- 
laced-Bildschirm ausgelegt. Für Interlaced- 
Modi ist die zweite (Short Frame) Copper- 
Liste zu patchen und die Berechnung der 
Vertikalposition mit zwei zu multiplizieren. 
Jedenfalls gelingt es mit dem Lichtgriffel 
wesentlich besser, seinen Namen auf den 
Bildschirm zu pinseln, als das mit der teuer¬ 
sten Maus möglich wäre. Die ideale Anwen¬ 
dung für einen Lichtgriffel ist demzufolge 
nicht das Zeichnen, sondern die Auswahl von 
Menüfeldern und Gadgets. 

Wie funktioniert ein Lichtgriffel? Auf den 
ersten Blick grenzt es schon fast an Zauberei, 
wenn man mit einem Stift über den Bild¬ 
schirm fährt und dort zeichnen kann, als wäre 
es eine Schiefertafel. Woher sieht denn der 
Bildschirm, wo sich der Lichtgriffel befin¬ 
det? Wieso kann der Bildschirm überhaupt 
etwas sehen? 

Das Prinzip ist simpel: Der Custom-Chip 
Agnus, verantwortlich für das Video-Timing 
des Amiga, enthält zwei Register, die sowohl 
die augenblickliche vertikale als auch hori¬ 
zontale Position des Elektronenstrahls bein¬ 
halten. Sie werden normalerweise permanent 



inkrementiert und zu Beginn eines neuen 
Durchlaufs wieder auf Null gesetzt (Bild 2). 

Die unteren 8 Bit von VHPOS enthalten 
die aktuelle horizontale Strahlposition in 
einer Auflösung von zwei Lowres- oder vier 
Hires-Pixeln (Vi 60 des Bildschirms), da HO 
fehlt. Der Wert für die horizontale Position 
kann zwischen $00 und $e3 (0 bis 227 dezi¬ 
mal) liegen. Die horizontale Rücklaufperiode 
liegt zwischen $0f bis $35. Die oberen 8 Bit 
zusammen mit dem Bit 0 von VPOS geben 
die aktuelle vertikale Strahlposition an, die- 
sesmal in der vollen Auflösung von einer 
Rasterzeile (pro Halbbild 0 bis 312, also 625 
Zeilen in PAL). Die vertikale Rücklaufperi¬ 
ode reicht von 0 bis 25. Zusätzlich enthält 
VPOS noch 1 Bit, das im Interlaced-Modus 
bei jedem ungeraden Halbbild gesetzt ist. 
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Bild 1: Die Anschlußbelegung des 
Amiga-Gameports und die Bedeutung 
der einzelnen Pins sowohl für den 
Light-Pen als auch für den Joystick 

Ein Lichtgriffel besteht aus einem Foto¬ 
transistor mit einer kleinen Schmitt-Trigger- 
Schaltung, die in dem Moment, in dem der 
Elektronenstrahl am Fototransistor des Licht¬ 
griffels vorbeisaust, einen Impuls erzeugt. 
Der Lichtgriffeleingang des Amiga reagiert 
auf diesen Impuls und stoppt augenblicklich 
das Beamcounter-Register. Dieses läßt sich 
danach via Software auslesen. Es beinhaltet 
die Position, in der sich der Lichtgriffel 
befinden muß. Die Pixel-Position wird durch 
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Abzug eines Offsets aus der Strahlposition 
errechnet. Erst bei Beginn des nächsten Bil¬ 
des (nach Ende der vertikalen Austastlücke, 
also ab Zeile 26) wird der Zähler erneut 
gestartet. So läßt sich mit einem Lichtgriffel 
bis zu 50mal pro Sekunde eine Position 
ermitteln und Linien oder ähnliches auf den 
Bildschirm zaubern. 

Die Stoppmöglichkeit des Beamcounters 
ist normalerweise abgeschaltet, sonst würde 
auch bei einfachem Mausbetrieb ohne Licht¬ 
griffel die Betätigung der Maus oder eines 
Joysticks am Port 2 das Register VPOSR am 
Mitzählen hindern. Das sollte aber zur Fest¬ 
stellung der aktuellen Rasterstrahlposition 
jederzeit zur Verfügung stehen, z.B zum syn¬ 
chronisierten Bütten ohne Flimmereffekte. 
Für den Betrieb eines Lichtgriffels ist deshalb 
das LPEN-Bit (Bit 3 von BPLCONO) auf 
High zu setzen. 

Da das Betriebssystem keinerlei Software¬ 
unterstützung zum Betrieb eines Lichtgriffels 
liefert, ist alles zu Fuß zu programmieren - 
sogar die Copper-Liste muß gepatcht werden. 


da sie sonst das LPEN-Bit alle 50stel 
Sekunde wieder auf auf Null setzt. 

Jeder Lichtgriffel hat außer dem lichtemp¬ 
findlichen Sensor noch einen Schalter in der 
Schreibspitze, der geschlossen wird, wenn 
man den Bildschirm berührt und Druck aus¬ 
übt. Dieser Schalter wird vom Gameport 
ebenfalls abgefragt, wobei in offenem Zu¬ 
stand normalerweise keine Aktion ausgeführt 
wird. Die Light-Pen-Software kann leicht 
zwischen drei Zuständen unterscheiden: 

O Der Lichtgriffel hat ausgelöst (Elektronen¬ 
strahl wurde registriert) 

O Der Lichtgriffel hat nicht ausgelöst (Licht¬ 
griffel ist zuweit weg) 

O Der Schalter ist gedrückt (meist hat dann 
der Lichtgriffel auch ausgelöst) 

Es gibt nun noch ein paar Tücken: Der 
Elektronenstrahl ist nur dort zu registrieren, 
wo der Bildschirm nicht ganz dunkel ist. Es 
genügt, als Hintergrundfarbe Grau einzustel¬ 
len. Man kann aber auch absichtlich Teile des 
Bildschirms für den Lichtgriffel ausmaskie¬ 
ren, indem man dort einfach schwarze Berei¬ 


che zeichnet. Vorsicht ist auch bei Verwen¬ 
dung der Farbe Rot geboten. Die meisten 
Fotodioden und -transistoren in Lichtgriffeln 
registrieren kein Rot, also bleiben auch rote 
Bereiche unerkannt. Meistens klickt man mit 
der lichtempfindlichen Spitze jedoch auf ein 
Objekt, das hell auf dunkel abgebildet ist. 

Ob der Light-Pen ausgelöst wurde, ist rela¬ 
tiv unkompliziert festzustellen. Man liest die 
Strahlposition zweimal hintereinander aus 
den Registern. Sind die Werte identisch und 
liegen sie innerhalb des sichtbaren Bereichs, 
steht der Zähler still, der Light-Pen hat also 
ausgelöst. Noch einfacher ist es, während des 
Vertical-Blanking-Interrupts (0 < V < 25). 
Man liest die Register einmal. Liegt der Wert 
innerhalb des sichtbaren Bildes, ist er gültig. 

Bleibt die Feststellung, daß der Lichtgriffel 
zum Zeichnen zwar zu grob, zur Gadget-Aus- 
wahl direkt am Bildschirm und für Pro¬ 
gramme, die ohne Maus und ohne Tastatur 
auskommen, ideal geeignet ist. rz 

Literaturhinweise 

[1] Commodore Amiga. AMIGA ROM Kemel Reference Manual 
Hardware. Third Edition, Reading 1991 


1 

/* 

54 

struct Window ‘LPenWindow; 

2 

* LightPen Programm für Amiga 

55 

SHORT PenX,PenY,OldPenX,OldPenY,OldPen; 

3 

* Autor:Bernhard Emese 

56 

USHORT *Joy0Dat=(USHORT *)0xdff00a, 

4 

* Hier wird gezeigt, wie auf dem AMIGA eine Lightpen-Software 

57 

*JoylDat={USHORT *)Oxdff00c; 

5 

* aussehen kann. Alles, was man dafür braucht, ist der richtige 

58 

struct NewWindow nw = { 

6 

* Umgang mit den Beamposition Registern VPOS und VHPOS. 

59 

0,0, 

7 

* Der C-Source ist mit Aztec 5.0 lauffähig und kann leicht 

60 

WIDTH,HEIGHT, 

8 

* an LATTICE oder andere angepaßt werden. 

61 

0,1, 

9 

* Aufruf: cc lpen.c -ps 

62 

IDCMPFLAGS, 

10 

* ln lpen.o -lLIB:/cl6 

63 

WINDOWFLAGS, 

11 

* Sobald das Programm gestartet ist, kann man auf dem 

64 

NULL,NULL,NULL,NULL, NULL, 

12 

* Workbench-Screen in den Workbench-Farben mit einem Lichtgriffel 

65 

WIDTH,HEIGHT,WIDTH,HEIGHT, 

13 

* Linien zeichnen. Das Programm geht von einem Non-Interlaced 

66 

WBENCHSCREEN, 

14 

* Workbench-Screen aus. Mit Preferences muß die Hintergrundfarbe 

67 

); 

15 

* auf eine mindestens mittlere Helligkeit gesetzt werden, da 

68 


16 

* sonst der Lichtgriffel nicht anspricht. Vorsicht auch bei Farbe 

69 

/* 

17 

* Rot. Manche Griffel können dann nichts »sehen«. 

70 

* Initialisieren der Lichtgriffel Schnittstelle. Leider ist das 

18 

* Leider funktioniert der Lichtgriffel nicht mit Flickerfixer- 

71 

* Amiga-Betriebssystem ein Feind des Lichtgriffels, denn die 

19 

* Karten. Die verzögerte Ausgabe der Bildinformation führt dort 

72 

* Copperliste der Intuition-Screens setzt das sogenannte LPEN-Bit 

20 

* natürlich zu völlig falschen Positionswerten. Außerdem wird 

73 

* ständig zurück. Da diese Copperliste sehr vielfältig 

21 

* durch das Patchen der Copperliste die Anzeige des Bildschirms 

74 

* aussehen kann, muß sie Befehl für Befehl nach dem verflixten 

22 

* beeinflußt. Beim Amiga 3000 muß der Schalter des integrierten 

75 

* Rücksetzbefehl - oder auch mehreren - durchsucht werden, die 

23 

* Flickerfixers in Stellung aus gebracht werden. 

76 

* dann gepatcht werden. Der Bildschirm wird gelöscht und oben 

24 

*/ 

77 

* links wird eine kleine Palette gezeichnet. 

25 

#include <functions.h> 

78 

*/ 

26 

tinclude <exec/types.h> 

79 

void InitLPen(struct View ‘View) { 

27 

#include <intuition/intuitionbase.h> 

80 

register USHORT i,*w; 

28 

#include <intuition/intuition.h> 

81 

/* Zum Betrieb des Lichtgriffels muß Bit 3 LPEN von BPLCONO 

29 

#include <hardware/custom.h> 

82 

* gesetzt werden. Weil BPLCONO aber in der Copperliste 

30 

#include <graphics/gfxbase.h> 

83 

* verwendet wird, muß die Copperliste gepatcht werden. Gesucht 

31 


84 

* wird der Befehl MOVE BPLCONO,#xx 

32 

/*** Defines ***/ 

85 

*/ 

33 

#define LEFT.BUTTON 0x40 /* Linker Mausknopf am CIA-Port */ 

86 


34 

fldefine DXOFFSET 20 /* Zum Justieren des X-Werts */ 

87 

if(View->LOFCprList) { 

35 

#define PENDOWN (1«9) /* für VC-64 Lichtgriffel */ . 

88 

w=View->LOFCprList->start; /* w zeigt auf den Beginn der 

36 

#define BEAMDETECT (1«0) /* interne Bits der LPen Routine */ 

89 

Copperliste */ 

37 

#define PENPRESSED (1«1) 

90 

/* alle Befehle durchsuchen */ 

38 

#define WIDTH 640 /* Grösse des Zeichenwindows */ 

91 

for(i=0;i<View->LOFCprList->MaxCount;i++,w+=2) { 

39 

#define HEIGHT 256 

92 

if(*w==0xffff && *(w+l)==0xfffe) 

40 

#define IDCMPFLAGS NULL /* keine IXMP-Messages */ 

93 

break; /* WAIT ffff beendet die Copperliste */ 

41 

#define WINDOWFLAGS {ACTIVATE 1 BORDERLESS) /* Ohne Border */ 

94 

if (*w==0x0100) * (w+1) I =1«3; 

42 

/* Hardwareregister */ 

95 

/* Befehl gefunden LPEN-Bit setzen (Bit 3) */ 

43 

44 

#define custom (‘((struct Custom *)Oxdff000)) 

96 

} 

45 

/*** Prototypes ***/ 

97 

98 

} 

/* ab jetzt ist Light-Pen Modus aktiviert. Zum Auswählen der 

46 

void InitLPen(struct View *View); 

99 

* Farben werden vier Gadgets gezeichnet 

47 

USHORT LPen(struct View *View); 

100 

*/ 

48 


101 

SetDrMd(LPenPort,JAM1); 

49 

/*** Variablen ***/ 

102 

SetRast(LPenPort,0); /* Hintergrund löschen */ 

50 

struct IntuitionBase ‘IntuitionBase; 

103 

for(i=0;i<4;i++) { 

51 

struct GfxBase *GfxBase; 

104 

SetAPen(LPenPort,i); /* Lösch und Farbrechtecke zeichnen */ 

52 

struct View *LPenView; 

105 

RectFi11(LPenPort,i*20,0,i*20+20,10); 

53 

struct RastPort ‘LPenPort; 

106 

SetAPen(LPenPort,0); /* ausgefüllt mit Farbe 0 */ 
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107 

RectFill(LPenPort,i*20+5,3,i*20+15,7); 

190 

* ließen sich bei jedem Auftippen Objekte statt Linien zeichnen. 

108 

} 

191 

* Oben links befindet sich eine Farbpalette', aus der man sich 

109 

SetAPen(LPenPort,l); 

192 

* verschiedene Farben durch Auftippen auswählen kann. Die 

110 

) 

193 

* Schleife wird durch Drücken der linken Maustaste beendet 

111 


194 

*/ 

112 

/* 

195 

main() { 

113 

* Abfrage der Lichtgriffelposition. LPen liefert einen Code 

196 


114 

* zurück, der angibt, ob der Strahl erkannt wurde und ob 

197 

SHORT Code,i; 

115 

* zusätzlich die Schreibspitze des Griffels betätigt ist. 

198 

BOOL CrossHair=FALSE; 

116 

* Code=0: Lichtgriffel nicht erkannt, zu weit vom Bildschirm 

199 


117 

* entfernt 

200 

/* Öffnen der Libraries */ 

118 

* BEAMDETECT: Lichtgriffelposition erkannt, Position steht in PenX 

201 

IntuitionBase= (struct IntuitionBase *) 

119 

* und PenY 

202 

OpenLibrary("intuition.library*,NULL)? 

120 

* PENDOWN: Lichtgriffelspitze ist ausgelöst, das Zeichnen kann 

203 

GfxBase =(struct GfxBase *)OpenLibrary(*graphics.library',NULL); 

121 

* stattfinden 

204 


122 

* PENPRESSED : wird nur im Moment des Aufdrückens zusammen mit 

205 

if(GfxBase==0 II IntuitionBase==0) 

123 

* PENDOWN zurückgegeben 

206 

exit(10); 

124 

*/ 

207 


125 

USHORT LPen(struct View *View) { 

208 

if(!(LPenWindow=OpenWindow(&nw))) /* eigenes Fenster öffnen */ 

126 

register USHORT hl,h2,vpos,Code,Pen; 

209 

exit(10); 

127 

register ULONG pos; 

210 


128 


211 

LPenView=GfxBase->ActiView; 

129 

hl=custom.vhposr; /* Beamposition lesen */ 

212 

LPenPort=LPenWindow->RPort; 

130 

h2=custcm.vhposr; /* nochmal lesen */ 

213 

InitLPen(LPenView); /* Lichtgriffel aktivieren */ 

131 


214 


132 

if(hl!=h2) /* ungleich ? */ 

215 

do { 

133 

return(FALSE); /* wenn Register zählt, hat Lichtgriffel nicht 

216 

Code=LPen(LPenView); /* Lichtgriffelzustand abfragen */ 

134 

ausgelöst */ 

217 

if(Code & PENPRESSED) { 

135 

vpos=custom.vposr & 0x0001; /* V8 lesen */ 

218 

/* LPen liefert in den globalen Variablen PenX PenY die 

136 

219 

* Position des Lichtgriffels, falls er sich oben links 

137 

/* Horizontal-Überlauf abfangen, da Werte nur bis 0xe3 gehen */ 

220 

* befindet können Farben gewählt oder der Bildschirm 

138 

if ((h2=hU0xff) < 0x20) 

221 

* gelöscht werden 

139 

/* horizontal < 0x20 ist in Wirklichkeit rechter Bildrand */ 

222 

V 

140 

hl=(hl & OxffOO) ] (h2+0xe4); 

223 


141 


224 

if(CrossHair) DrawCrossHair(OldPenX.OldPenY); 

142 

/* kombinierte vertikal Horizontalposition V8-V0 H8-H1 */ 

225 

CrossHair=FALSE; /* Fadenkreuz löschen */ 

143 

p 0 S= (ULONG )vpos« 16 I hl; 

2*26 


144 


227 

if(PenY<10 && PenX<80) { /* Farbwahl oder Löschen ? */ 

145 

if (pos> (ULONG) (View->ViewPort->DHeight+View->DyOffset)«8) 

228 

if(PenX<20) 

146 

/* Vertikalposition ist zu groß, unterer Rand */ 

229 

InitLPen(LPenView); /* Bildschirm Löschen 1 * 

147 

return(FALSE); 

230 

eise 

148 


231 

SetAPen(LPenPort,PenX/20); /* Farbe wählen */ 

149 

/* wenn bis hier alles stimmt, ist BEAMDETECT erkannt */ 

232 

while(*JoylDat & PENDOWN); /* Griffel abgehoben? */ 

150 

Code=BEAMDETECT; 

233 

Code=0; 

151 


234 

} eise 

152 

/* X aus Strahlposition berechnen */ 

235 

/* immer wenn der Stift aufgesetzt wird, beginnt eine neue 

153 

PenX=((pos & OxOOff)«1)-View->DxOffset-DXOFFSET; 

236 

* Linie */ 

154 


237: 

Move(LPenPort,PenX,PenY); 

155 

/* bei HIRES verdoppeln */ 

238 

} 

156 

if(View->ViewPort->Modes & HIRES) PenX*=2; 

239 


157 


240 

/* Eine Linie wird gezeichnet, wenn der Griffel aufliegt und 

158 

/* Y aus Strahlposition errechnen */ 

241 

* sich seine Position verändert hat, ansonsten ist bei 

159 

PenY=((pos & OxlffOO)»8)-View->DyOffset; 

242 

* Annäherung des Lichtgriffels ein Fadenkreuz zu sehen 

160 


243 

*/ 

161 

Pen=*JoylDat & PENDOWN; /* Schreibknopf gedrückt? */ 

244 

if(Code & BEAMDETECT && !(Code & PENDOWN)) ( 

162 

if(Pen==PENDOWN) ( 

245 

if(CrossHair) 

163 

Code 1=PENDOWN; /* wenn ja setze PENDOWN Flag */ 

246 

DrawCrossHair(01dPenX,01dPenY); 

164 

if(OldPen!=PENDOWN) /* wenn vorher noch nicht gedrückt */ 

247 

DrawCrossHair(PenX,PenY); 

165 

Code 1=PENPRESSED; /* setze zusätzlich PENPRESSED Flag */ 

248 

CrossHair=TRUE; 

166 

) 

249 

} eise if(Code & BEAMDETECT && Code & PENDOWN && 

167 

OldPen=Pen; /* für nächste Abfrage abspeichern */ 

250 

(PenX!=01dPenX II PenY!=01dPenY)) { 

168 

return(Code); /* aufrufendes Programm bekommt die Flags */ 

251 

SetDrMd(LPenPort,JAM1); 

169 

) 

252 

Draw(LPenPort,PenX,PenY); 

170 


253 

} 

171 

/* 

254 

01dPenX=PenX? 

172 

* Zeichnet ein kleines Fadenkreuz auf den Bildschirm. Es soll 

255 

OldPenY=PenY; /* alte Position abspeichern */ 

173 

* verdeutlichen, daß nicht erst beim Auftippen der 

256 

) 

174 

* Lichtgriffelspitze, sondern schon bei der Annäherung 

257 

/* Linke Maustaste beendet das Programm */ 

175 

* an den Bildschirm die Position festgestellt werden kann. 

258 

while(*(UBYTE *)0xbfe001 & LEFT_BUTTON); 

176 

*/ 

259 


177 

DrawCrossHair(SHORT x,SHORT y) { 

260 

CloseWindow(LPenWindow); 

178 

SetDrMd(LPenPort,COMPLEMENT); 

261 

CloseLibrary(IntuitionBase); 

179 

Move(LPenPort,x-10,y)? 

262 

CloseLibrary(GfxBase); 

180 

Draw{LPenPort,x+10,y); 

263 


181 

Move(LPenPort,x,y-5)? 

264 

/* Die Copperliste wird automatisch korrigiert, wenn man einen 

182 

Draw(LPenPort,x,y+5); 

265 

* Screen herunterzieht 

183 

} 

266 

*/ 

184 


267 

} © 1993 M&T 

185 

/* 



186 

* Programm MainO initialisiert den Lichtgriffel und fragt den 

»LPen.c«: Das Programm demonstriert den Umgang 

187 

188 
189 

* Zustand zyklisch ab. Der Befehl Draw könnte auch durch einen 

* RectFill()- oder DrawCirclel)- oder BltBitMap()-Aufruf zum 

* Kopieren aus einer BitMap ersetzt werden. Dadurch 

mit einem Light-Pen am Amiga. Sie finden es auch auf 
der Diskette zum Heft (Seite 114). 
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Der 


Grundlagen Compiler-Bau 


Mini-Compiler 


Program 

PROGRAM [VarDeclaration] 
BEGIN {Statement} END . 

V arDeclaration 

VAR Identifier}Identifier}. 

Statement 

Assignment | While | Print . 

Assignment 

Identifer "=" Expression . 

Wliile 

WHILE Expression DO { 
Statement } END . 

Print 

PRINT Expression 

Expression 

[ "+" | ] Factor { ( "+" | 

) Factor } . 

Factor 

Identifier | Constant. 

Identifier 

Letter { Letter } . 

Constant 

Digit { Digit } . 

Letter 

"a" | .. | "z" j "A" | .. | "Z" . 

Digit 

"0" | .. | "9" . 


Die Syntax der Miniprogranimiersprache in EBNF-Notation 


Compiler-Bau ist eines der inter¬ 
essantesten Gebiete der Infor¬ 
matik. Im folgenden finden Sie 
daher das erforderliche Grund¬ 
wissen über die Funktionsweise 
und den Aufbau eines Compilers. 

von Fridtjof Sieben 

A ufgabe eines Compilers ist es, einen in 
einer abstrakten Programmiersprache 
geschriebenen Quelltext in ein gleich¬ 
wertiges Programm einer anderen, meist 
simpleren, Zielsprache zu übersetzen. Ein 
Compiler besteht gewöhnlich aus drei Modu¬ 
len: dem Scanner, dem Parser und dem Code¬ 
generator. 

□ Aufgabe des Scanners ist es, den Text des 
Quellprogramms, der im allgemeinen als 
ASCII-Datei vorliegt, in eine Folge von Sym¬ 
bolen der Quellsprache zu wandeln. Diese 
Symbole lassen sich später leichter verarbei¬ 
ten als einzelne Zeichen des Textes. 

□ Der Parser erhält die Symbole als Eingabe. 
Er interpretiert die Symbolfolge und prüft, ob 
das Quellprogramm der Syntax der Quell¬ 
sprache entspricht. Dabei findet der Parser 
auch heraus, aus welchen Elementen der Syn¬ 
tax das Programm besteht. 

□ Der letzte Programmteil, der Codegenera¬ 
tor, erzeugt aus den vom Parser erhaltenen 
Informationen ein gleichwertiges Programm 
der Zielsprache. 

Mini 

Betrachten wir als Beispiel für eine 
Quellsprache die Sprache »Mini«. Die Abbil¬ 
dung zeigt ihre Syntax. Zur Beschreibung der 
Syntax wird die weit verbreitete »erweiterte 
Backus-Naur-Form« (EBNF, [1]) verwendet. 
Ähnlichkeiten mit Modula-2 sind unverkenn¬ 
bar, allerdings ist sie viel einfacher. Alle 
Variablen sind automatisch vom Typ »INTE¬ 
GER«. Der Typ wird bei der Deklaration 
daher nicht angegeben. Als Anweisungen 
kennt Mini nur die Zuweisung, eine Schleife 
und eine Ausgabefunktion. Die Schleife wird 
wie in Modula-2 mit dem Schlüsselwort 
»WHILE« eingeleitet. Sie wird solange 
durchlaufen, bis der Ausdruck hinter WFIILE 
den Wert 0 annimmt. 

Bei Ausdrücken erlaubt Mini nur das 
Rechnen mit den Operatoren »+« und »-«. 
Trotz der Simplizität lassen sich mit Mini 
kleinere Programme schreiben. Das Minipro¬ 
gramm »Fibonacci.mini« (Listing 1) errech¬ 
net die ersten 46 Fibonacci-Zahlen und gibt 
sie auf dem Bildschirm aus (eine Fibonacci- 


Zahl ist die Summe der beiden vorhergehen¬ 
den Fibonacci-Zahlen, wobei die ersten zwei 
den Wert 1 besitzen). 


1 

PROGRAM 

2 


3 

VAR 

4 

a,b,c 

5 


6 

BEGIN 

7 

a = 1 

8 

b = 0 

9' 

c = 46 

10 

WHILE c DO 

11 

PRINT a 

12 

a = a + b 

13 

b = a - b 

14 

c = c - 1 

15 

END 

16 

END 

17 


18 

© 1993 M&T 

Listing 1. Unser »Mini«-Programm be- 

rechnet die ersten 46 Fibonacci-Zahlen 


Jetzt geht es darum, einen Mini-Compiler 
zu schreiben. Als Sprache verwenden wir 
Amiga-Oberon. Der Compiler läßt sich mit 
Amiga-Oberon 2.14/3.0 oder der Demover¬ 
sion von Amiga-Oberon 3.0 [2] übersetzen. 
Die Demoversion finden Sie auch auf der 
Diskette zum Heft (siehe Seite 114). 


Der Scanner 

Zunächst benötigen wir den »Mini-Scan¬ 
ner« (Listing 2). Der Scanner soll den Quell¬ 
text, der als gewöhnliche Textdatei vorliegt, 
in eine Symbolfolge zerlegen. Für jedes Sym¬ 
bol wird dazu eine (INTEGER-)Konstante 
definiert. Die Symbole sind die reservierten 
Wörter, spezielle Zeichen (Komma, Gleich¬ 
heitszeichen usw.), Bezeichnernamen und 
Konstanten. Das spezielle Symbol »eof« 
kennzeichnet das Ende der Quelltextdatei. 

Der Scanner exportiert die Prozedur »Get- 
Sym«, die das jeweils nächste Symbol des 
Quelltextes bestimmt und die Variable sym 
auf die für dieses Symbol vorgesehene Kon¬ 
stante setzt. Ist das Symbol ein Bezeichner 
(»ident«), wird zusätzlich der Bezeichner¬ 
name in der Variablen »identifier« abgelegt. 
Ist es eine Konstante (»const«), wird ihr Wert 
in »constant« gesichert. 

Von der Prozedur »GetChar« erhält Get- 
Sym nacheinander die Zeichen des Quelltex¬ 
tes. Mehrere aufeinanderfolgende Buchsta¬ 
ben werden zusammengefaßt und mit den 
reservierten Wörtern verglichen. Bilden sie 
ein reserviertes Wort, wird die Konstante des 
entsprechenden Symbols, ansonsten ident in 
die Variable sym geschrieben. Trifft der 
Scanner auf Ziffern, berechnet er den Wert 
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der so gebildeten Dezimalzahl und speichert 
ihn in der Variablen constant: sym wird auf 
const gesetzt. Bei speziellen Zeichen wird 
sym auf die für diese Symbole definierte 
Konstante gesetzt. Ein Zeichen, das keinem 
Symbol der Sprache Mini entspricht, führt zu 
einer entsprechenden Fehlermeldung und 
zum Programmabbruch. 


1: MODULE Scanner; 

2: IMPORT F : = FileSystem, R := Requests; 

3: 

4: CONST (* Symbole von Mini *) 

5: program * =0; var * = 1; begin * = 2; 

6: end * =3; while * = 4; do * = 5; 

7: print * =6; comma * = 7; equal * = 8; 

8: plus * =9; minus * =10; ident * = 11; 

9: const * =12; eof * = 13; 

10: MaxIdLen * = 79; 

11: 

12: TYPE Identifier * = ARRAY MaxIdLen+1 OF C 
HAR; 

13: 

14: VAR 

15: source * : F.File; (* Quelltextdatei*) 
16: char : CHAR; (* zuletzt gel 

esenes Zeichen (0X bei EOF) *) 

17: sym - : INTEGER; (* das letzte 

Symbol (program, var, etc.) *) 

18: identifier- : Identifier; (* der Bezeich 
ner bei sym=ident *) 

19: constant - : LONGINT; (* die Konstan 

te bei sym=const *) 

20: 

21: PROCEDURE GetChar; 

22: BEGIN IF - F.Read(source,char) THEN char 
:= 0X END END GetChar; 

23: 

24: PROCEDURE GetSym*; 

25: VAR i: INTEGER; 

26: BEGIN 

27: WHILE (char>0X) & (char<=" ") DO GetChar 
END; (* Space, LF, etc. *) 

28: CASE CAP(char) OF 

29: I "A".."Z": (* Bezeichner oder Schlü 

sselwort *) 

30: i := 0; 

31: REPEAT 

32: identifier[i] := char; 

33: INC(i); 

34: GetChar; 

35: UNTIL (i=MaxIdLen) OR (CAP(char)<*A") 

OR (CAP(char)>"Z*); 


36: 

identifierfi} := 

0X; 


37: 

IF identifier 

= "PROGRAM 

" THEN sym 


:= program 



38 

ELSIF identifier 

= "VAR" 

THEN sym 


:= var 



39 

ELSIF identifier 
:= begin 

= "BEGIN" 

THEN sym 

40 

ELSIF identifier 
:= end 

= "END" 

THEN sym 

41 

ELSIF identifier 
:= while 

= "WHILE" 

THEN sym 

42 

ELSIF identifier 
:= do 

= "DO" 

THEN sym 

43 

ELSIF identifier 
:= print 

= "PRINT" 

THEN sym 

44: 

ELSE 



45: 

sym := ident; 

(* 

Kein Schlüs 


selwort, also Bezeichner *) 


46: 

END; 



47: 

1 "0".."9": 




(* Konstante Zahl *) 


48: 

constant := 0; 



49: 

REPEAT 



50: 

constant := 10*constant + 

ORD(char) - 


ORD("0"); GetChar; 



51: 

UNTIL (char<"0") 

OR (char>* 

9"); 

52: 

sym := const; 



53: 

1 "=": sym := equal; GetChar; 



(* Sonderzeichen *) 


54: | ",": sym := comma; GetChar; 

55: I "+*: sym := plus ; GetChar; 

56: I *-": sym := minus; GetChar; 

57: I 0X : sym := eof; 

58: ELSE R.Fail("Unerwartetes Zeichen!") END 

59: END GetSym; 

60: 

61: BEGIN char := ■ " END Scanner. © 1993 M&T 

Listing 2: Das Scanner-Modul überprüft 
den Quelltext Bezeichnern 


Der Parser 

Nun gilt es, den Parser zu entwerfen. Bei 
vielen Sprachen - vor allem bei den 
Wirth "sehen - bietet sich ein Parser an, der 
nach dem Prinzip des rekursiven Abstiegs 
arbeitet [1]. Auch für Mini wählen wir diese 
Methode. Für komplexere Sprachen gibt's 
aufwendigere Algorithmen; sie werden in [3] 
ausführlich beschrieben. Listing 3 enthält den 
Quelltext des Mini-Parsers. Die Aufrufe der 
Routinen aus dem Modul Code sind nicht 
Teil des Parsers. Wir gehen später darauf ein. 

Ein mit rekursivem Abstieg arbeitender 
Parser enthält für die Symbole aus der 
EBNF-Syntax der untersuchten Sprache 
jeweils eine Prozedur. Diese Prozeduren 
haben die Aufgabe, das entsprechende 
Sprachkonstrukt zu untersuchen. Aus der in 
EBNF gegebenen Syntax-Beschreibung läßt 
sich ohne Umwege direkt ein rekursiver 
Abstiegs-Parser erzeugen. 

Es ist zweckmäßig, mit dem »oberen« 
Symbol der Grammatik zu beginnen - bei 
Mini ist es das Symbol »Program«. Die 
gleichnamige Prozedur des Parsers wertet 
dieses Symbol aus. Zunächst überprüft sie, 
ob der Quelltext mit dem Schlüsselwort 
»PROGRAM« beginnt. Da an verschiedenen 
Stellen im Parser ein bestimmtes Symbol zu 
checken ist, wurde hierfür die Prozedur 
»Chk« implementiert. Chk liest auch gleich 
das folgende Symbol ein. 


1: MODULE Parser; 

2 : 

3: IMPORT S := Scanner, R := Requests, Code; 
4: 

5: PROCEDURE Chk(sym: INTEGER; msg: ARRAY OF 
CHAR); 

6: BEGIN IF S.sym=sym THEN S.GetSym ELSE R.F 
ail(msg) END END Chk; 

7: 

8: PROCEDURE VarDeclaration; 

9: (* VarDeclaration -> VAR Identifier {"," 
Identifier} . *) 

10: BEGIN 

11: REPEAT 

12: S.GetSym; 

13: IF S.sym#S.ident THEN R.FaiK"Bezeich 

ner in erwartet!") END; 

14: Code.DCL(S.identifier); 

15: S.GetSym; 

16: UNTIL S.sym#S.comma; 

17: END VarDeclaration; 

18: 

19: PROCEDURE Factor; 

20: {* Factor -> Identifier I Constan 

t . *) 

21: BEGIN 

22: CASE S.sym OF 

23: I S.ident : Code.MOVEvarDO (S.identifi 

er); S.GetSym; 

24: I S.const : Code.MOVEconstDO(S.constant 


25: 

26: 

27: 

28: 

29: 

30: 

31: 

32: 

33: 

34: 

35: 

36: 

37: 

38: 

39: 

40: 

41: 

42: 

43: 

44: 

45: 

46: 

47: 

48: 

49: 


); S.GetSym; 

ELSE R.Fail("Faktor erwartet") END; 

END Factor; 

PROCEDURE Expression; 

(* Expression -> [ "+* I "-' ] Factor 
{ ( "+• I ) Factor } . *) 

VAR neg: BOOLEAN; (* muß DO negiert wer 
den? *) 

BEGIN 

neg := FALSE; 

IF S.sym IN {S.plus,S.minus} THEN neg : 
= S.sym=S.minus; S.GetSym END; 

Factor; 

IF neg THEN Code.NEGD0 END; 

WHILE S.sym IN {S.plus,S.minus} DO 
neg := S.sym=S.minus; S.GetSym; 
Code.MOVEDODl; 

Factor; 

IF neg THEN Code.NEGD0 END; 
Code.ADDDlDQ; 

END; 

END Expression; 


PROCEDURE Statement; 


(* Statement 
Print . 

{* Assignment 
sion . 

(* While 

{ Statement } END 
(* Print 


-> Assignment I While I 
*) 

-> Identifer '=' Expres 
*) 

-> WHILE Expression DO 
. *) 

-> PRINT Expression 

*) 


50: VAR 

51: varname: S.Identifier; 

(* Z;el einer Zuweisung *) 

52: Start,end : INTEGER; 

(* Labels bei einer Schleife *) 

53: BEGIN 

54: CASE S.sym OF 

55: I S.ident: varname := S.identifier; S.G 

etSym; (* Zuweisung *) 

56: Chk(S.equal,*'=' erwartet!") 


57: 

58: 

59: 

60: 

61: 

62: 

63: 

64: 

65: 

66 : 

67: 

68 : 

69: 

70: 


Expression; 

Code.MOVEDOvar(varname); 

I S.while: S.GetSym; 

(* Schleife *) 

Start := Code.GetLabelO; en 
d := Code.GetLabelO; 

Code.Label (Start); 
Expression; 

Chk(S.do,"DO erwartet!"); 
Code.TSTD0; Code.BLE(end); 
WHILE S.sym#S.end DO Stateme 

nt END; 

Chk(S.end,"END erwartet!"); 
Code.BRA(Start); Code.Label( 

end); 

I S.print: S.GetSym; Expression; Code.P 
rintDO; (* Ausgabe *) 

ELSE R.Fail("Statement erwartet!") END; 
END Statement; 


71 


72: PROCEDURE Program*; 

73: (* Program -> PROGRAM [ VarDeclaration ] 
BEGIN { Statement } END. *) 

74: VAR Start: INTEGER; 

75: BEGIN 


76: S.GetSym; Chk(S.program,"PROGRAM erwart 

et!"); 

77: Start := Code.GetLabel(); Code.BRA(star 

t); 

78: IF S.sym=S.var THEN VarDeclaration END; 

79: Chk(S.begin,"BEGIN erwartet!"); 

80: Code.StartUp(Start); 

81: WHILE S.sym#S.end DO Statement END; 

82: Code.CleanUp; 

83: Chk(S.end,"END erwartet!"); 

84: END Program; 

85: 

86: END Parser. © 1993 M&T 


Listing 3: Dem Parser-Modul checkt das 
Programm auf korrekte Synta 
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1: MODULE Code; 

2: 

3: IMPORT io; 

4: 

5: VAR labels: INTEGER; 

6: 

7: PROCEDURE W (s: ARRAY OF CHAR); BEGIN io. 
WriteString(s) END W; 

8: PROCEDURE WL(s: ARRAY OF CHAR); BEGIN W(s 
); io.WriteLn END WL; 

9: 

10; PROCEDURE DCL*(var: ARRAY OF CHAR); (* 
Speicher für var reservieren *) 

11; BEGIN W(var); WLC: dc.l 0') END DCL; 

12; 

13: PROCEDURE MOVEvarDO*(var: ARRAY OF CHAR); 

(* var nach DO kopieren *) 

14: BEGIN WC MOVE.L "); W(var); WLC,DO" 
) END MOVEvarDO; 

15: 

16: PROCEDURE MOVEconstDO*(c: LONGINT); 

C Konstante c nach DO laden *) 

17: BEGIN WC MOVE.L #"); io.Writelnt(c,0 
); WL C,DO") END MOVEconstDO; 

18: 

19: PROCEDURE MOVEDOvar*(name: ARRAY OF CHAR) 
; ("DO in DO kopieren *) 

20: BEGIN WC MOVE.L DO,"); WL(name) END 
MOVEDOvar; 

21: 

22: PROCEDURE MOVED0D1*; BEGIN WL(" MOVE.L 
DO,Dl") END MOVEDOD1; 

23: PROCEDURE ADDD1D0 *; BEGIN WLC ADD.L 
Dl,DO") END ADDD1D0; 

24: PROCEDURE NEGDO *; BEGIN WLC NEG.L 

DO" ) END NEGDO; 

25: PROCEDURE TSTDO *;• BEGIN WLC TST.L 

DO" ) END TSTDO; 

26: 

27: PROCEDURE GetLabelM): INTEGER; 

(* neues Label anfordern *) 

28: BEGIN INC(labels); RETURN labels END GetL 
abel; 

29: 

30: PROCEDURE Label*(1: INTEGER); 

(* Label <1> ausgeben *) 

31: BEGIN W("L"); io.WriteHex(l, 3) ; VfL (": -) E 
ND Label; 

32: 

33: PROCEDURE BLE*(1: INTEGER); 

(* BLE <1> erzeugen *) 

34: BEGIN WC BLE L"); io.WriteHex(l,3 

); WL("") END BLE; 

35: PROCEDURE BRA*{1: INTEGER); 

(* BRA <1> erzeugen *) 

36: BEGIN WC BRA L"); io.WriteHex(l,3 

); WLC") END BRA; 

37: 

38: PROCEDURE PrintDO*; 




* Wert von DO ausgeben 1 

k ) 

39 

BEGIN 



40 

WLC 

LEA 

_format,A0") 


41 

WLC 

MOVE.L 

A0,Dl * ) 


42 

WLC 

LEA 

_print,A0" ) 


43 

WLC 

MOVE.L 

A0,D2" ) 


44 

WLC 

MOVE.L 

DO,(A0)" ) 


45 

WLC 

MOVE.L 

_dos, A6" ) 


46 

WLC 

JSR 

-954(A6) ) 


47 

END PrintDO; 


48 




49 

PROCEDURE StartUp*(Start: INTEGER); 


(* Dos-Library öffnen, etc. 1 

k ) 

50 

BEGIN 



51 

WL(". 

_dos: 

DC.L 0" ) 

52 

WLC. 

.dosname: 

DC.B 'dos.library',0") 

53 

WLC. 

_format: 

DC.B '%ld',10,0" ) 

54 

WLC 


DS.L 0" ) 

55 

WLC_print: 

DC.L 0" ) 

56 

Label(start); 


57 

WL(" 

LEA 

_dosname,Al" ) 

58 

WLC 

MOVE.L 

#37,DO" ) 

59 

WLC 

MOVE.L 

$4,A6" ) 

60 

WLC 

JSR 

-552(A6)" ) 

61 

WL(" 

TST.L 

DO" ) 

62 

WLC 

BNE.S 

_ok" ) 


63: WLC RTS" ); 

64: WL("_ok:* ); 

65: WLC . MOVE.L D0,_dos" ); 

66: END StartUp; 

67: 

68: PROCEDURE CleanUp*; (* 


Dos-Library schließen, etc. *) 

69: BEGIN 

70: WL(" MOVE.L _dos,Al" ); 

71: WLC MOVE.L $4,A6" ); 

72: WLC JSR -414(A6)"); 

73: WLC MOVE.L #0,D0" ); 

74: WL(* RTS" ); 

75: WLC END" ); 

76: END CleanUp; 

77: 

78: BEGIN labels := 0 END Code. © 1993 M&T 

Listing 4: Das Code-Modul generiert 
den adäquaten Assembler-Code. 

Der optionale Variablendeklarationsteil 
wird im Parser mit einer IF-Anweisung aus¬ 
gewertet: Trifft der Parser auf das Symbol 
»VAR«, springt der die Prozedur »VarDecla- 
ration« an. Im Deklarationsteil dürfen sich 
beliebig viele, mindestens jedoch eine, Varia¬ 
blendeklaration befinden. Daraus folgt, daß 
die Untersuchung am einfachsten mit einer 
REPEAT-Schleife durchzuführen ist. 

Die dem Schlüsselwort »BEGIN« folgen¬ 
den »Statements«, deren Anzahl im übrigen 
unbegrenzt sein darf, wertet man am besten 
mit einer WHILE-Schleife aus. Ein State- 


1: MODULE Mini; 

2 : 

3: IMPORT Parser, Scanner, F := FileSystem, 

R := Requests, Arguments; 

4: 

5: VAR name: ARRAY 80 OF CHAR; 

6 : 

7: BEGIN 

8: R.Assert(Arguments.NumArgs()=1,"Aufruf: 

Mini <Quelltext>"); 

9: Arguments.GetArg(1,name); 

10: R.Assert(F.Open(Scanner.source,name,FAL 

SE),"Text nicht gefunden!"); 

11: Parser.Program; 

12: IF F.Close(Scanner.source) THEN END; 

13: END Mini. © 1993 M&T 

Listing 5: Im Hauptmodul laufen alle 
Fäden zusammen. 


ment setzt sich aus drei Alternativen zusam¬ 
men: »Assignment«, »While« und »Print«. 
Eine Case-Anweisung zur Auswertung 
erscheint hier am sinnvollsten. Um nicht im 
Wust zuvieler Prozeduren die Übersicht zu 
verlieren, belassen wir es in diesem Fall bei 
einer: der Prozedur »Statement«. Diese wer¬ 
tet alle Anweisungen direkt aus. 

Beim Abarbeiten der WHILE-Schleife 
wird deutlich, weshalb die Parsing-Methode 
»rekursiver Abstieg« heißt: Um die Anwei¬ 
sungen im Schleifenrumpf zu untersuchen, 
ruft man die Prozedur Statement rekursiv auf. 

Ausdrücke und Faktoren werden von den 
Prozeduren »Expression« bzw. »Factor« 
geprüft. Im Vergleich zu den bisher bespro¬ 
chenen Funktionen enthalten sie jedoch 
nichts entscheidend Neues. Um schnell fest¬ 
zustellen, ob das aktuelle Symbol einer der 
Operatoren + oder - ist, wird dieses mit der 
Menge »{S.plus,S.minus}« verglichen. 


Der Codegenerator 

In den bisherigen Teilen sind sich viele 
Compiler sehr ähnlich. Die wirklich interes¬ 
santen Aufgaben kommen erst jetzt auf uns 


1 

BRA 

L001 

2 

a: dc.l 0 


3 

b: dc.l 0 


4 

c: dc.l 0 


5 

_dos: 

DC.L 0 

6 

_dosname: 

DC.B 'dos.library',0 

7 

_format: 

DC.B ‘%ld',10,0 

8 


DS.L 0 

9 

_print: 

DC.L 0 

10 

L001: 


11 

LEA 

_dosname,Al 

12 

MOVE.L 

#37,DO 

13 

MOVE.L 

$4, A6 

14 

JSR 

-552(A6) 

15 

TST.L 

DO 

16 

BNE.S 

_ok 

17 

RTS 


18 

_ok: 


19 

MOVE.L 

D0,_dos 

20 

MOVE.L 

#1,D0 

21 

MOVE.L 

D0,a 

22 

MOVE.L 

#0, DO 

23 

MOVE.L 

D0,b 

24 

MOVE.L 

#46,DO 

25 

MOVE.L 

D0,c 

26 

L002: 


27 

MOVE.L 

c, DO 

28 

TST.L 

DO 

29 

BLE 

L003 

30 

MOVE.L 

a,D0 

31 

LEA 

_format,A0 

32 

MOVE.L 

A0,D1 

33 

LEA 

_print,A0 

34 

MOVE.L 

A0,D2 

35 

MOVE.L 

DO,(A0) 

36 

MOVE.L 

_dos,A6 

37 

JSR 

-954(A6) 

38 

MOVE.L 

a,D0 

39 

MOVE.L 

DO, Dl 

40 

MOVE.L 

b,D0 

41 

ADD.L 

Dl, DO 

42 

MOVE.L 

D0,a 

43 

MOVE.L 

a,D0 

44 

MOVE.L 

DO, Dl 

45 

MOVE.L 

b, DO 

46 

NEG.L 

DO 

47 

ADD.L 

Dl, DO 

48 

MOVE.L 

D0,b 

49 

MOVE.L 

c, DO 

50 

MOVE.L 

DO, Dl 

51 

MOVE.L 

#1,D0 

52 

NEG.L 

DO 

53 

ADD.L 

Dl, DO 

54 

MOVE.L 

D0,c 

55 

BRA 

L002 

56 

L003: 


57 

MOVE.L 

_dos,Al 

58 

MOVE.L 

$4,A6 

59 

JSR 

-414(A6) 

60 

MOVE.L 

#0, DO 

61 

RTS 


62 

END 

© 1993 M&T 

Listing 6. Der von Mini erzeugte Assem- 

bler-Code für das Fibonacci-Programm 


zu. Der Codegenerator formuliert die Bedeu¬ 
tung des Quellprogramms in der Zielsprache. 
Die Effizienz des übersetzten Programms 
hängt entscheidend von der Qualität des 
Codegenerators ab. Als Zielsprache wählen 
wir 68000-Assembler-Quelltext, der mit auf 
dem Amiga verbreiteten Assemblern in 
Maschinencode zu übersetzen ist. Geeignet 
ist beispielsweise der frei kopierbare Assem¬ 
bler »a68k« von Charlie Gibb [4]. 
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Die meisten Compiler erzeugen direkt 
Maschinencode und speichern ihn als Objekt¬ 
datei oder als ausführbares Programm. Wir 
legen keinen besonderen Wert auf die Effizi¬ 
enz, dennoch ist der erzeugte Code akzepta¬ 
bel. Für die Erzeugung der Anweisungen der 
Zielsprache ist es zweckmäßig, spezielle 
Funktionen zu schreiben, ln unserem Beispiel 
sind sie im Modul »Code« (Listing 4) zusam¬ 
mengefaßt. Das erzeugte Assembler-Pro¬ 
gramm wird mit den Prozeduren des Moduls 
»io« einfach auf dem Bildschirm ausgegeben. 

»DCL« generiert die Assembler-Anwei¬ 
sung »dc.l 0«. Sie reserviert Speicher für eine 
Variable. Die Adresse der Variablen wird mit 
einem Label (Markierung) versehen. Dabei 
verwenden wir den Variablennamen. 

Die Befehle »MOVEvarDO«, »MOVE- 
constDO«, »MOVEDOvar« und »MOVE- 
D0D1« bilden die entsprechenden Move- 
Befehle mit Variablen, Registern oder Kon¬ 
stanten als Argument. »ADDD1D0«, 
»NEGDO« und »TSTDO« entsprechen den 
gleichnamigen Assembler-Befehlen für die 
Prozessorregister Dl und DO. 

Für Sprunganweisungen im Zielprogramm 
benötigen wir weitere Label. Diese werden 
auch vom Modul Code verwaltet. Dabei ist 
jedes Label vor der Verwendung mit »GetLa- 
bel« anzufordern. Das Ergebnis ist ein der 
Markierung eindeutig zugeordneter Integer- 
Wert. Die Prozedur »Label« gibt die überge¬ 
bene Marke an der aktuellen Position im 
Zielprogramm aus. »BLE« und »BRA« 
erzeugen die entsprechenden bedingten bzw. 
unbedingten Verzweigungsbefehle mit dem 
übergebenen Label als Ziel. 

Anders als die bisherigen Prozeduren des 
Codemoduls erzeugt »Print« eine ganze 
Palette Assembler-Befehle, die den Wert des 
Registers DO mit der Routine »VPrintf« der 
DOS-Library (V37) ausgeben [5]. Die von 
unserem Mini-Compiler erzeugten Pro¬ 
gramme sind also nur ab Betriebssystem 2.0 
oder höher lauffähig. 

»Single Pass«: Über¬ 
setzung in einem 
Durchlauf 

»StartUp« und »CleanUp« erzeugen den 
Code, der zu Beginn bzw. am Schluß des 
Programms ausgeführt werden muß. Hier fin¬ 
det man einige Variablen- und Konstantende¬ 
finitionen. Weiterhin wird die DOS-Library 
geöffnet bzw. geschlossen. Sollen die Pro¬ 
gramme auch von der Workbench lauffähig 
sein, ist der Startup-Code entsprechend zu 
erweitern [6]. 

Ein effizienter Compiler arbeitet meist 
nach dem sog. »single pass«-Prinzip. Dabei 
wird in einem einzigen Durchlauf der Quell¬ 
text untersucht und das Zielprogramm 
erzeugt. Um das zu erreichen, erweitert man 
den Parser, um die für die Codeerzeugung 
nötigen Anweisungen. Bei unserem Mini- 
Compiler sind dies die Aufrufe der Routinen 


des Codemoduls im Modul Parse (Listing 3). 
Der erste Befehl erzeugt in der Prozedur 
»Program« einen Sprung an den Anfang des 
Startup-Codes. Zudem wurde »Program« um 
die Aufrufe von »Code.StartUp« und 
»Code.CleanUp« erweitert. 

ln »VarDeclaration« wird mit Code.DCL 
Speicher für die Variablen reserviert. Für die 
Auswertung von Faktoren und Ausdrücken 
wählt man hier ein relativ einfaches Verfah¬ 
ren: Nach einem Aufruf von Factor bzw. 
Expression befindet sich der Wert des Fak¬ 
tors bzw. des Ausdrucks immer im Register 
DO. In Expression muß der Wert des ersten 
Faktors daher in ein anderes Register (hier 
Dl) gerettet werden, bevor Factor erneut auf¬ 
rufbar ist. Dies geschieht mit dem von 
Code.MOVEDODl erzeugten Move-Befehl. 

Für eine Zuweisung wird in der Prozedur 
Statement ein einfacher Move-Befehl 
erzeugt, der den Wert des in DO stehenden 
Ausdrucks in den für die Variable reservier¬ 
ten Speicher schreibt. 

Mini schafft sogar 
Schleifen 

Eine Schleife zu übersetzen ist etwas auf¬ 
wendiger. Hier gibt man zunächst das Label 
»Start« vor der Schleife aus. Dann wird der 
Schleifenausdruck berechnet und geprüft, ob 
er kleiner oder gleich 0 ist. Ist das der Fall, 
springt man ans Label »end« hinter der 
Schleife. Ansonsten führt man den Schlei¬ 
fenrumpf aus und verzweigt wiederum zur 
Markierung Start. Für eine Print-Anweisung 
wird die im Modul »Code« programmierte 
Routine verwendet. 

Der Compiler 

Es ist soweit. Die drei Bestandteile des 
Compilers, der Scanner, der Parser und der 
Codegenerator, sind fertig und lassen sich zu 
einem Programm zusammenfügen. Mini 
(Listing 5) ist das Hauptmodul des Compi¬ 
lers. Der an Mini übergebene Quelltext wird 
in Assembler-Code übersetzt und auf dem 
Bildschirm ausgegeben. Mit dem Aufruf 
Mini >Fibonacci.s Fibonacci.mini 
wird das Beispielprogramm »Fibonacci, 
mini« (Listing 1) ins Assembler-Programm 
»Fibonacci.s« (Listing 6) übersetzt. 
a68k Fibonacci.8 

assembliert das Programm. Mit dem PD-Lin- 
ker »BLink« oder dem Oberon-Linker 
»OLink« läßt sich nun ein ausführbares Pro¬ 
gramm erzeugen: 

BLink Fibonacci.o TO Fibonacci 
oder 

OLink FROM Fibonacci.o TO Fibonacci 

Optimierungen 

Der bisher beschriebene Mini-Compiler 
legt keinen Wert auf die Generierung von 
besonders effizientem Code. Bei kommer¬ 
ziellen Compilern ist das jedoch nötig, um 
die Programmierung in Assembler überflüs¬ 
sig zu machen. 


Einer der wichtigsten Aspekte eines guten 
Codegenerators ist die Registervergabe und 
Registerausnutzung. Insofern sollte der Com¬ 
piler möglichst alle Prozessorregister nutzen 
und nicht, wie unser Mini-Compiler lediglich 
zwei. Viele Zugriffe auf den Speicher - und 
somit auch wertvolle Rechenzeit - läßt sich 
so einsparen, wenn sich der Compiler merkt, 
welche Werte öder Variableninhalte in Regi¬ 
stern enthalten sind. Dann müssen Variablen 
nicht ständig neu gelesen werden; es können 
statt dessen direkt die Werte aus den Regi¬ 
stern verwendet werden. 

Wichtig wird auch ein Schutzmechanismus 
für Register, wenn ein Compiler für eine 
Sprache entwickelt wird, die komplexere 
Ausdrücke als die von Mini erlaubten ermög¬ 
licht. Beim Auswerten eines Teilausdrucks 
dürfen die Zwischenergebnisse anderer Teil¬ 
ausdrücke, die in Prozessor-Registern gespei¬ 
chert sind, nicht überschrieben werden. 

Eine einfache aber sehr sinnvolle Optimie¬ 
rung ist über einen sog. »Peephole-Optimi- 
zer« (Guckloch-Optimierer) möglich. Dabei 
werden einzelne Assembler-Befehle unter¬ 
sucht, bevor sie ins Zielprogramm geschrie¬ 
ben werden. Können sie durch gleichwertige, 
schnellere oder kürzere Befehle ersetzt wer¬ 
den, benutzt der Compiler selbstverständlich 
diese. Typische Beispiele sind etwa die Mul¬ 
tiplikation mit einer zweier-Potenz: Sie kann 
durch eine einfache Schiebeoperation ersetzt 
werden. Eine Addition der Konstanten 0 wird 
ignoriert. 

Optimierungen: Aus 
Mini wird Maxi 

Bei der Übersetzung geschachtelter Kon¬ 
trollstrukturen (z.B. »if-then-else«) und 
Schleifen entstehen oft unnötige Sprungan¬ 
weisungen, etwa eine bedingte auf eine unbe¬ 
dingte. Diese lassen sich insofern optimieren, 
daß die bedingte Sprunganweisung gleich ans 
Ziel der unbedingten springt. Zudem kann 
hierbei auch gleich nach »totem« Code 
gesucht werden. Mit totem bezeichnet man 
Code, der einer unbedingten Sprunganwei¬ 
sung folgt und auf den selbst keine Sprungan¬ 
weisung existiert. Dieser kann komplett aus 
dem Zielprogramm entfernt werden. 

Es gibt viele Möglichkeiten, den hier 
beschriebenen Mini-Compiler weiterzuent¬ 
wickeln. Es ist sogar recht einfach, neue 
Funktionen (z.B. neue Rechenoperationen) 
oder fehlende Kontrollstrukturen (z.B. eine 
if-Anweisung) zu implementieren. Vielleicht 
kann der Compiler sogar soweit ergänzt wer¬ 
den, daß er eine brauchbare kleine Sprache 
übersetzt. rz 

Literatur und Software: 

(1 ] Niklaus Wirth: Compilerbau. BG Teubner Stuttgart. 1986 
[2) Fridtjof Sieben: Amiga Oberon 3.0 Demo, AMOK 75 
[3| Alfred V. Aho. Ravi Sethi. Jeffrey D. Ullman: Compilerbau. 
Addison-Wesley 1988 
(4) Charlie Gibb: a68k. Fish 521 

15] Commodore-Amiga Inc.: The AmigaDOS Manual. 3rd Edition. 
Bantam Books 1991 

[6] Commodore-Amiga Inc.: Amiga ROM Kemel Reference 
Manual Libraries, 3rd Edition, Addison-Wesley 1992 


34 


Faszination Programmieren Nr. 1 




GRUNDLAGEN 


■■■■■■■■■1 

■■■■■■■■■■■■■■■■■■■■■■III 



Algorithmen für Strategiespiele 




Programmieren 


mit Taktik 


Die Künstliche Intelligenz übertrifft im Bereich der 
Strategiespiele heute schon die natürliche Intelli¬ 
genz der meisten Menschen. Wie ist es mög¬ 
lich, daß aus einem Rechenknecht, der im 
Grunde nur Nullen und Einsen in seinem 
Speicher verknüpft und verschiebt, ein intelli¬ 
genter Spielpartner wird? Die grundlegenden 
Algorithmen sollen hier erläutert werden. 

Als Beispiel für die Umsetzung in 
ein MODULA-2-Programm stellen 
wir Ihnen die Strategieroutinen 
von »SOGO« vor. 


von Bernfried Brüggemann 


D ie Spielregeln für SOGO sind einfach: 
In das SOGO-Spielbrett (Bild) werden 
in einer 4x4-Anordnung insgesamt 16 
Stifte aufgestellt. Auf jeden lassen sich je 4 
Kugeln auffädeln. Insgesamt sind 64 Kugeln 
im Spiel, 32 weiße und 32 schwarze. Der 
Spieler mit den weißen Kugeln beginnt. 
Beide Spieler setzen abwechselnd eine Kugel 
ihrer Farbe und versuchen, eine Mühle zu bil¬ 
den. Eine Mühle besteht aus 4 Kugeln einer 
Farbe in einer Reihe. Im Spielfeld sind 16 
senkrechte, 40 waagerechte, 18 diagonale 
und 2 raumdiagonale Mühlen möglich. Wer 
zuerst eine Mühle mit seinen Steinen gebildet 
hat, gewinnt. 

Erst die Theorie... 

Bei Strategiespielen wie Schach, Go oder 
auch SOGO besitzen beide Spielpartner 
jederzeit alle Informationen über den aktuel¬ 
len Spielzustand. Es gibt keine verdeckten 
Karten und auch der Zufall in Gestalt des 
Würfels spielt keine Rolle. Der Spielablauf 
ist im Prinzip genau kalkulierbar. Die Spiel¬ 
regeln legen die möglichen Züge in jeder 
Spielstellung eindeutig fest. Die Spieler kön¬ 
nen daraus völlig frei den Zug auswählen, 
den sie für den besten halten. 

Strategiespiele dieser Art sind Nullsum¬ 
menspiele. Bei Spielende entspricht der 
Gewinn des einen dem Verlust des anderen 
Spielers. Ein Unentschieden oder Remis ist in 
diesem Sinne ein Sonderfall. 

Der Spielbaum 

Auf den ersten Blick scheinen Spiele wie 
Schach, Go oder SOGO sehr verschieden. Sie 
haben unterschiedliche Spielbretter, andere 
Figuren und vor allem verschiedene Spielre¬ 
geln. Im wesentlichen sind sich alle Strate¬ 
giespiele dieser Art jedoch sehr ähnlich. Das 


In 

der Spiel¬ 
baumdarstellung 
unterscheiden sich ver¬ 
schiedene Strategiespiele nur 
noch in der Zahl der Verästelungen an 
jedem Knoten, der Zahl der Züge von der 
Wurzel bis zu einer Endstellung und in der 
Bewertung dieser Endstellungen. Man sieht 
dem fertig konstruierten Baum nicht mehr an, 
welche Spielregeln zugrunde liegen. Sie sind 
in der Baumstruktur verborgen. 

Minimaxverfahren 

So einen Spielbaum entwickelt der Com¬ 
puter bei der Suche nach dem besten Zug und 
testet systematisch alle möglichen Züge. Am 
Beispiel von Bild 2 auf der folgenden Seite 
kann man seinen »Gedankengang« verfolgen. 

In Stellung A ist der Computer (Weiß) am 
Zug. Er zieht probeweise nach B und nimmt 
im ersten Schritt an, daß der Gegenzug von 
Schwarz zur Stellung C führt. Hier ist der 
Computer wieder am Zug. Er wählt aus den 
Endstellungen a, b und c die mit der günstig¬ 
sten Bewertung, also b. Der Wert 0 dieser 
Stellung wird für die Stellung C eingetragen. 

Der Rechner geht zur Stellung B zurück 
und zieht im zweiten Schritt nach D. Dort 
erreicht der Computer mit Stellung f sogar 
den Wert 8 und trägt ihn für Stellung D ein. 

Wieder kehrt der Rechner zur Stellung B, 
um im dritten Schritt den Gegenzug nach E 
zu testen. Dort wird der Wert 6 eingetragen. 

Damit sind alle möglichen Gegenzüge von 
Schwarz in Stellung B ausgetestet. Welchen 
Gegenzug wird Schwarz wählen? Schwarz 


wird deutlich, 
wenn man ihren 
Spielbaum be¬ 
trachtet. Der Spiel¬ 
baum gibt einen Über¬ 
blick aller im Spiel mö 
liehen Stellungen. 

Bild 1 zeigt an einei 
spiel die Grundstruktur eines 
Spielbaums. Die Zweige entspre¬ 
chen den möglichen Zügen, die Kno¬ 
ten den jeweils erreichten Stellungen. 

Im Beispiel symbolisiert die Wurzel A des 
Spielbaums die Anfangsstellung des Spiels. 
Von dort führen drei Züge zu den Folgestel¬ 
lungen B, F und J. Der Spielbaum mündet 
schließlich in die Knoten der Endstellungen 
a-ö des Spiels. Die Spielregeln bestimmen 
die Bewertung der Knoten als Gewinn oder 
Verlust. Beim Schach entsprechen Matt-, 
Remis- oder Pattstellungen den Endknoten. 

Die Tiefe einer Stellung im Spielbaum gibt 
an, wieviel Züge von der Wurzel bis zu die¬ 
ser Stellung nötig sind. Die Endstellungen in 
Bild 1 haben somit alle die Tiefe 3. 


Bild 1: Grundstruktur eines Spiel- 
baums; ob Go, Schach oder SOGO 
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zieht so, daß der Computer (Weiß) an¬ 
schließend nur noch möglichst schlecht 
bewertete Endstellungen erreichen kann und 
wählt daher die Position C. Der Wert 0 dieser 
Stellung wird für den Knoten B notiert. 

Von der Wurzelstellung ausgehend werden 
in gleicher Weise die Zweige F... und J... 
untersucht, ln den Knoten B, F und J stehen 
dann die Bewertungen der besten Endstellun¬ 
gen, die der Rechner bei jeweils optimalem 
Gegenzug von Schwarz erreichen kann. Der 
Rechner wählt als besten Zug den, der zur 
maximal bewerteten Stellung B führt. 

Diese Methode, den besten Zug zu finden, 
nennt man Minimaxverfahren. Abwechselnd 
wählen die Spieler entsprechend ihrer Inter¬ 
essenlage die maximal (Weiß) oder die mini¬ 
mal (Schwarz) bewertete Folgestellung. Die 
Bewertung der Endstellungen (Gewinn > 0, 
Remis = 0, Verlust < 0) muß dabei aus der 
Sicht des Spielers vorgenommen werden, der 
in der Wurzelstellung am Zug ist. 


Man kann das Minimaxverfahren natürlich 
nicht nur anwenden, um in der Anfangsstel¬ 
lung am Wurzelknoten des Spielbaumes den 
besten Zug zu finden. Wegen der Selbstähn¬ 
lichkeit des Spielbaums kann man jeden 
Knoten einer Folgestellung wieder als Wur¬ 
zel eines Unterbaumes ansehen. Das Mini¬ 
maxverfahren findet also in jeder denkbaren 
Stellung eines Strategiespiels den besten Zug. 

Die Komplexität von Spielbäumen realer 
Spiele wie Schach oder SOGO setzt der 
Anwendung des Minimaxverfahrens jedoch 
schnell Grenzen. Der SOGO-Spielbaum ver¬ 
zweigt sich in den Knoten in 16 Folgestellun¬ 
gen. Die Endknoten des Baums werden nach 
64 Zügen erreicht, wenn alle Kugeln gesetzt 
sind. Man muß also mit 16 hoch 64 = 10 


hoch 77 Endknoten rechnen. Diese Zahl wird 
nicht ganz erreicht, weil viele Partien schon 
nach weniger als 64 Zügen enden und weil 
nicht in allen Stellungen wegen bereits voll¬ 
besetzten Stiften 16 Züge möglich sind. 
Trotzdem bleibt eine gigantische Zahl mög¬ 
licher Endstellungen. 

Beim Schach rechnet man mit ca. 10 hoch 
120, bei Go gar mit 10 hoch 740 Endstellun¬ 
gen. Um auch nur über den ersten Zug zu 
entscheiden, müßte das Minimaxverfahren 
die Bewertung aller Endknoten verarbeiten. 
Das wäre selbst für die schnellsten bekannten 
Computer eine Arbeit von Jahrtausenden. 

Heuristische Bewertung 

Es gibt nur einen Ausweg: Man muß den 
Spielbaum vereinfachen. Einen Spielbaum 
mit 10 hoch 3 bis 10 hoch 4 Endknoten kann 
ein Computer wie der Amiga noch in ange¬ 
messener Zeit mit dem Minimaxverfahren 
bearbeiten. Wenn in einem SOGO-Spielbaum 
die Endstellungen bereits in einer Tiefe von 3 


Zügen lägen, wäre demnach die Auswertung 
von 16 hoch 3 = 4096 Endknoten noch zu 
bewältigen. Man erreicht das, indem man 
willkürlich alle Stellungen in der Tiefe 3 zu 
Endstellungen erklärt. 

Das Minimaxverfahren erfordert jedoch für 
die Endknoten eine Bewertung nach Gewinn 
und Verlust. Bei echten Endstellungen ist es 
offensichtlich, welcher Spieler gewonnen hat. 
Bei den willkürlichen Endstellungen in der 
Tiefe 3 ist Gewinn oder Verlust noch nicht 
sicher vorherzusagen, das ist ja gerade der 
Reiz eines Strategiespiels. Man muß hier 
sinnvolle Kriterien für die Stellungsbewer¬ 
tung finden (griech.: heuriskein). Beim 
Schach könnte man die Anzahl der Figuren 
betrachten. Je mehr eigene Figuren je weni¬ 


ger gegnerischen gegenüberstehen, um so 
höher der Wert der Stellung. Beim SOGO ist 
eine Stellung günstig bewertet, in der viele 
potentielle Mühlen mit möglichst vielen eige¬ 
nen Kugeln besetzt sind. 

Die Spielstärke des Minimaxverfahrens auf 
dem verkürzten Spielbaum hängt stark ab 
von den Bewertungskriterien für die willkür¬ 
lichen Endknoten. Der beste Zug wird nicht 
mehr mit 100%iger Sicherheit gefunden. Bei 
gleichen Bewertungskriterien - eine gewisse 
Güte dieser Kriterien sei vorausgesetzt - 
steigt die Spielstärke, wenn die willkürlichen 
Endstellungen in eine größere Tiefe verlegt 
werden. Der Rechner schaut dann im Spiel¬ 
geschehen weiter voraus, muß allerdings eine 
höhere Zahl von Endknoten bearbeiten. Wie 
bereits bemerkt, setzt der AMIGA hier je¬ 
doch eine Grenze von ca. 4000. 

Wieder bleibt nur ein Ausweg: der Spiel¬ 
baum muß noch weiter vereinfacht werden. 

Alfa/Beta-Pruning 

Ohne weitere heuristische Zusatzannah¬ 
men, allein aufgrund logischer Überlegungen 
kann der Spielbaum noch weiter gestutzt 
werden (to prune: schneiden, stutzen). Wenn 
man den Suchvorgang des Minimaxverfah¬ 
rens genauer untersucht, stellt man nämlich 
fest, daß die Bewertung einiger Knoten das 
Endergebnis gar nicht beeinflussen kann. 

Man betrachte z.B. Stellung B in Bild 3. 
Das Minimaxverfahren übernimmt für diesen 
»min«-Knoten aus C, D und E den Wert der 
minimal bewerteten Stellung: 

Wert(B) = min(Wert(C),Wert(D),Wert(E)). 

Im ersten Schritt bestimmt der Rechner 
den Wert von Knoten C aus den Endknoten a, 
b und c. Wie in der Wurzel ist Weiß am Zug. 
Daher erhält der »max«-Knoten C den maxi¬ 
malen Wert der Folgestellungen a, b und c: 
Wert(C) = max(Wert(a),Wert(b)»Wert (c)) 

= max(-l,0,-2) = 0 

Bereits an dieser Stelle steht fest, daß B 
den Wert 0 nicht mehr überschreiten kann: 
Wert(B) = min(Wert(C),Wert(D),Wert(E)) 

= min( 0 »Wert(D)»Wert(E))<= 0. 

Der Rechner speichert diese obere Grenze 
beta = 0 als vorläufigen Wert von B. 

Wie kann die Bewertung von D und E die¬ 
sen Wert von B noch beeinflussen? Wenn D 
und E mit einem Wert größer als beta bewer¬ 
tet werden, bleibt es bei dem Wert beta = 0. 
Nur wenn der Wert von D oder E kleiner als 
beta ausfällt, wird B noch geändert und erhält 
diesen kleineren Wert von D oder E. 

Um die Frage zu entscheiden, ist die Stel¬ 
lung D zu bewerten. Hier ist wie in der Wur¬ 
zel Weiß am Zug. Das Minimaxverfahren 
ordnet dem »max«-Knoten D daher den 
maximalen Wert der Endknoten d, e und f zu: 
Wert(D) = max(Wert(d)»Wert(e)»Wert(f)). 

Der erste Endknoten d liefert den Wert 7. 
Ganz egal, welche Werte die Endknoten e 
und f besitzen, der Wert von D kann nicht 
kleiner als 7 werden: 

Wert(D) = max(7,Wert(e),Wert(f)) >= 7 

Damit ist aber Wert(D) > beta und hat kei¬ 
nen Einfluß mehr auf die Bewertung von B: 
Wert(B) = min(0» 7 o. größer, Wert(E)) <= 0 



Bild 2: Bewertung der Spielbaumknoten mit dem Minimaxverfahren 
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Die Auswertung der Endstellungen e und f 
kann an dieser Tatsache nichts ändern. Der 
Computer kann die Zeit für die Bewertung 
der Knoten sparen. Sobald an einem »max«- 
Knoten die Beta-Abbruch-Bedingung: 

Wert(»max«-Knoten) > beta 

erfüllt ist, kann also die weitere Auswertung 

des Knotens abgebrochen werden. Auch die 

Auswertung des »max«-Knotens E kann 

wegen der Beta-Bedingung 

Wert(E) >= 6 > beta 

schon nach dem Besuch des Endknotens g 
abgebrochen werden: B erhält den Wert 0. 


Eine entsprechende Überlegung wie für 
den »min«-Knoten B kann man auch für den 
»max«-Knoten A anstellen. B wird den Wert 
0 liefern, soviel ist bereits bekannt. Da A ein 
»max«-Knoten ist, kann der Wert von A 
nicht mehr kleiner als dieser Wert 0 werden. 
Wert (A)= max(Wert (B) ,Wert(F) ,Wert(J)) 

= max( 0 ,Wert(F),Wert (J) ) >= 0 

Die untere Grenze alfa = 0 ist der vorläu¬ 
fige Wert von A. A wird nur dann die Werte 
von F oder J annehmen, wenn sie größer sind 
als alfa. Wenn die Werte von F und J kleiner 
sind als alfa, übernimmt A den Wert 0 von B. 

Das Minimaxverfahren wertet als nächsten 
den »min«-Knoten F aus. 

Wert(F)=min(Wert(G),Wert(H),Wert(I)) 

Die Endknoten j, k, 1 verleihen dem Kno¬ 
ten G den Wert -3. Da F ein »min«-Knoten 
ist, kann der Wert von F auch nach der Aus¬ 
wertung von H und I nicht mehr größer wer¬ 
den als der Wert -3 von G. 

Wert (F)=min(-3, Wert (H) .Wert (J) ) <= -3 
Damit ist Wert(F) < alfa und kann die 
Bewertung von Knoten A nicht beeinflussen: 
Wert(A)=max(0,-3 oder kleiner,Wert(J)) >=0. 

Die Auswertung der Zweige H und I ist 
also völlig überflüssig und kann ohne Infor¬ 
mationsverlust unterbleiben. 


Sobald an einem »min«-Knoten die alfa- 
Abbruch-Bedingung: 

Wert("min"-Knoten) < alfa 
erfüllt ist, kann die weitere Auswertung die¬ 
ses Knotens abgebrochen werden. Über die 
Parameter alfa und beta informieren die 
Elternknoten, also ihre Folgeknoten, wann es 
sinnlos ist, einen Zweig weiter auszuwerten. 
Zu Beginn wird am Wuzelknoten die 
alfa/beta-Schere geöffnet, d.h. alfa = -unend¬ 
lich und beta = -»-unendlich gesetzt. Alfa wird 
ausschließlich an »max«-Knoten verändert. 
Wenn die vom gerade bearbeiteten Folgekno¬ 


ten zurückgelieferte Bewertung größer ist als 
der momentane alfa-Wert, wird alfa auf den 
Wert dieses Folgeknotens erhöht. 

Umgekehrt wird beta nur an »min«-Knoten 
modifiziert: Wenn die vom gerade bearbeite¬ 
ten Folgeknoten gelieferte Bewertung kleiner 
ist als der momentane beta-Wert, wird beta 
auf den Wert dieses Folgeknotens erniedrigt. 
Alfa liefert den Grenzwert der Abbruch-Be¬ 
dingung an »min«-Knoten, während beta die¬ 
sen Grenzwert für »max«-Knoten darstellt. 
Die Tabelle gibt eine Übersicht des das spie¬ 
gelbildlichen Verhaltens von alfa und beta. 


Bedingung 

Max-Knoten 

Min-Knoten 

W>a 

ot=W 


W<a 


a-Abbruch 

W>ß 

ß-Abbruch 


W<ß 


ß=W 


Tabelle: Handhabung der alfa/beta- 
Schere; wann ist ein Knoten wichtig? 


Alfa und beta werden von den Elternkno¬ 
ten an die folgenden Knoten weitergegeben. 
Eine Modifikation der Parameter an den Fol¬ 
geknoten darf nicht den Wert von alfa oder 


beta bei den Elternknoten verändern, sonst 
wird möglicherweise gerade der Knoten mit 
der besten Bewertung abgeschnitten und der 
beste Zug wird nicht gefunden. Bei der 
Deklaration der weiter unten besprochenen 
Prozedur »Zug« tauchen daher alfa und beta 
als Wertparameter und nicht als variable 
Parameter in der Parameterliste auf. 

Wenn wie beim Knoten F die Abbruchbedin¬ 
gung schon in geringer Tiefe greift, kann der 
Spielbaum ohne Informationsverlust um 
ganze Zweige gestutzt werden. 

Ein Vergleich mit dem unbeschnittenen 
Spielbaum zeigt die Effektivität des alfa/beta- 
Prunings. Wenn sich jeder Knoten des Spiel¬ 
baums in b Folgeknoten verzweigt und die 
Endknoten sich in der Tiefe t befinden, sind 
ohne alfa/beta-Pruning 
NO = b fc 

Endknoten auszuwerten. Bei geradzahliger 
Baumtiefe kann das alfa/beta-Pruning diese 
Zahl reduzieren auf 
N(tgerade)=2* (b (t/2> ) -1 

Bei ungeradzahliger Baumtiefe bleiben 
N (tungerade )=b ((t+1,/21 + b <(t ‘ I,/2) -1 
auszuwertende Endknoten. 

Die Spielbaumtiefe wird durch alfa/beta- 
Pruning also scheinbar halbiert. Bei gleicher 
Rechenzeit kann daher der Spielbaum bis zur 
doppelten Tiefe durchsucht werden; das be¬ 
deutet einen beträchtlichen Gewinn an Spiel¬ 
stärke. Die angegebenen Formeln für die 
Zahl der auszuwertenden Endknoten sind 
allerdings untere Grenzwerte, die in der Pra¬ 
xis nicht ganz erreicht werden. Das hängt 
damit zusammen, daß in ungünstig sortierten 
Spielbäumen die Möglichkeit eines Abbruchs 
erst erkannt wird, wenn die überflüssigen 
Zweige längst durchsucht worden sind. 

Der Knoten J in Bild 3 zeigt dafür ein Bei¬ 
spiel. Die alfa-Abbruchbedingung greift erst 
nach der Bearbeitung des Folgeknotens L. 
Wenn L zuerst bearbeitet würde, entfielen 
sowohl Zweig K und M. Wird L aber erst 
nach der Auswertung von K oder M bearbei¬ 
tet, wird zwar die Abbruchmöglichkeit er¬ 
kannt, aber die Rechenzeit für die Zweige K 
oder M ist vergeudet. Das SOGO-Programm 
versucht, durch geschickte Sortierung des 
Spielbaums solche Situationen zu vermeiden. 

... und die Praxis 

Nach soviel grauer Theorie soll jetzt gezeigt 
werden, wie man Mini max verfahren und 
alfa/beta-Pruning in einem konkreten Spiel¬ 
programm an wendet. 

Programmstruktur: 

Ein Strategie-Spielprogramm für den 
Amiga sollte vier Grundfunktionen besitzen: 

□ Intuition-Anwender-Oberfläche 

□ grafische Darstellung des Spielbretts und 
der Figuren 

□ Kontrolle des Spielablaufs 

□ Künstliche Intelligenz, um den besten Zug 
zu finden 

Das in Modula-2 geschriebene Spielpro¬ 
gramm SOGO folgt diesem Schema und ist 
in vier Module gegeliedert: O 



Bild 3: alfa/beta-Pruning beschneidet den Spielbaum nochmals 
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□ sogomain.mod enthält die Intuition-Ober¬ 
fläche; 

□ sogograph.mod besorgt die Darstellung 

□ sogoctrl.mod kontrolliert den Spielablauf 
und die Einhaltung der Spielregeln; 

□ sogostrat.mod findet mit Minimaxverfah¬ 
ren und alfa/beta-Pruning den besten Zug; 

Bild 4 zeigt den Zusammenhang der vier 
SOGO-Moduln. An der Spitze der Hierarchie 
steht das Modul sogomain. Hier werden beim 
Programmstart Screen und Windows geöff¬ 
net. Anschließend verwaltet sogomain die 
Intuition-Ereignisse. Wird beispielsweise ein 
Menüpunkt angeklickt, ruft sogomain eine 
Prozedur aus den Moduln sogoctrl oder sogo- 
graph auf, die das Gewünschte erledigt. 



Bild 4: IMPORT von Prozeduren ist 
nur in Pfeilrichtung möglich 


Die in Listing 1 bis 3 aufgelisteten Defini¬ 
tionsmoduln geben einen Überblick der im¬ 
plementierten Prozeduren. Die wichtigsten 
Menüfunktionen sind im Kasten »Was bietet 
das SOGO-Menü ?« beschrieben. 


DEFINITION MODüLE sogoctrl; 

PROCEDÜRE BeginNewGame; 

(* startet eine neue SOGO-Partie *) 

PROCEDÜRE Human; 

(♦ setzt ein Flag, sodaß der AMIGA nur das Spielbrett für 
2 menshl. Spieler liefert *} 

PROCEDÜRE Computer; 

l* setzt ein Flag, sodaß 90GO gegen den AMIGA gespielt wird *) 
PROCEDÜRE AutoPlay; 

(* setzt ein Flag, sodaß AMIGA gegen sich selbst spielt *) 
PROCEDÜRE Black; 

(* Spieler 1 führt die weißen Kugeln, Spieler 2 die schwarzen *) 
PROCEDÜRE White; 

(* Spieler 1 führt die schwarzen Kugeln, Spieler 2 die weißen •) 
PROCEDÜRE LoadORSaveGame(LorS:INTEGER); 

(‘ lädt oder sichert eine SOGO-Partie *) 

PROCEDÜRE TakeBackLastMove; 

(* nimnt einen Zug zurück *) 

PROCEDÜRE DisplayStrings; 

(* schreibt die erweiterten Status-Infos ins Status-Window *) 
PROCEDÜRE GameHandler; 

(* kontrolliert den Spielablauf *) 

END sogoctrl. © 1993 M&T 

Listing 1: Das Modul »Sogoctrl.def« 
kontrolliert den Spielablauf 


Den Spielablauf kontrolliert eine zyklisch 
von sogomain aus aufgerufene Prozedur 
gamehandler im Modul sogoctrl. Falls der 
Computer am Zug ist, aktiviert gamehandler 
den Strategiemodul sogostrat und setzt mit 
der Prozedur Zug die Künstliche Intelligenz 
des Amiga in Gang, die dann je Spielstärke 
einen mehr oder weniger guten Zug findet. 
Der gamehandler stellt diesen Zug mit der 
Prozedur DrawHiddenFigure aus dem Modul 
sogograph auf dem Bildschirm dar. 

Wenn im nächsten Zyklus sogomain wie¬ 
derum den gamehandler aufruft, bearbeitet 
dieser dann den Zug des Amiga-Gegenspie- 
lers. Über die Prozedur FigPicked aus sogo¬ 
graph erfährt der gamehandler, welcher 
SOGO-Stab angeklickt wurde, und stellt den 
gewünschten Zug, falls er den Spielregeln 
genügt, ebenfalls am Bildschirm dar. 

Tips für Tüftler 

Das Modul-Grundgerüst kann man im 
Prinzip für andere Strategiespiele praktisch 
1:1 übernehmen. Da in allen Strategie-Spiel¬ 



- Menügruppe Playing: 

* Begin New Game 

* Choose Your Opponent 

* Choose Level 

* Choose Siele 

* Save This Game 

* Load A Saved Game 

* Quit 

nimmt Kugeln vom Brett und beginnt eine Partie. Weiß hat den ersten Zug. 
wählt Spielpartner. Human bedeutet ein Spiel mit einem menschlichen Gegenüber. 
Computer wählt den Amiga als Gegenspieler. 

AutoPlay läßt den Amiga gegen sich selbst spielen, 
legt die Spielstärke des Amiga fest. Seine Antwortzeit nimmt mit wachsendem Level 
von weniger als 1 s (Level 1) bis auf einige Minuten (Level 5) zu. Level 6 und 7 können 
auf einem normalen AMIGA mehrere Stunden Bedenkzeit benötigen, 
wählt die Kugelfarbe des 1. Spielers, 
sichern eines Spiels 

lädt ein gesichertes Spiel und setzt die Kugeln auf das Spielbrett, 
beendet das SOGO-Programm. 

Menügruppe View: 

* Set Colours 

* Type of View 

* Rotate Board 

öffnet ein Fenster mit Gadgets zur Änderung der Farbein sie 11 ungen. 

wählt zwischen 2-D- und 3-D-Darstellung (Rot-Grün-Filterbrille erforderlich) 

öffnet ein Fenster für die Einstellung des Blickwinkels auf das Spielbrett. 

- Menügruppe Options 

* Take Back Last Move 

* Status-Info 

nimmt die zuletzt gesetzte Kugel wieder vom Brett. 

wählt aus. ob im Status-Window nicht nur der aktuelle Spielzustand sondern auch der 
Gedankengang des AMIGA bei der Suche nach dem besten Zug dargestellt werden soll. 

Das Status-Window enthält folgende Informationen: 

+ wer ist am Zug; 

+ den Spielausgang (Gewinner oder "REMIS"); 

+ ein horizontales Balkendiagramm; die Zahl der Balken richtet sich nach der gewählten Suchtiefe im Spielbaum; 

jedem Balken entspricht eine bestimmte Tiefenstufe 
+ die vorgegebene Spielstärke, der die Zahl der vorausberechneten Halbzüge entspricht. 

+ Zahl der durch die alpha/beta-Bedingung abgeschnittenen Zweige des Spielbaumes; 

+ Gesamtzahl der bewerteten Spielstellungen; 


programmen die gleichen Grundfunktionen 
realisiert werden müssen, werden sich die 
verschiedenen Programme zumindest im 
Hauptmodul (sogomain) und auf der Ebene 
der Definitionsmoduln sehr ähnlich sein. Die 
Unterschiede sind in den jeweiligen Imple¬ 
mentationsmoduln realisiert. Das ist ein¬ 
leuchtend: eine Prozedur DrawBoard bringt 
in einem Schachspiel ein anderes Spielbrett 
auf den Bildschirm als im SOGO-Spiel. 

Wenn man vom SOGO-Modul-Grund- 
gerüst ausgehend ein anderes Strategiespiel 
programmieren will, sollte man mit der Intui¬ 
tion-Oberfläche beginnen. Die durch Menü¬ 
klick aufzurufenden Funktionen kann man 
zunächst in den Implementationsmoduln als 
Dummyprozedur in der Form 
PROCEDÜRE DrawBoard; 

BEGIN 

END DrawBoard; 

schreiben. Man hat dann von Anfang an ein 
lauffähiges Programm, das in allen Phasen 
der Programmentwicklung getestet werden 
kann. Außerdem programmiert es sich leich¬ 
ter, wenn man immer wieder sichtbare Fort¬ 
schritte erzielt. 


DEFINITION MODULE sogograph; 

FROH SYSTEM IMPORT ADDRESS; 

FROM Intuition IMPORT ScreenPtr,WindowPtr,Menu; 

FROH Graphics IMPORT RastPortPtr? 

TYPE Figtype = (black,white.phantom.pin); 


ARRAY16 

ARRAY[i..l6] OF INTEGER; 

SpielScreenPtr 

ScreenPtr; 

SpielWindowPtr 

WindowPtr; 

SpielWinRPPtr 

RastPortPtr; 

SpielMenu 

ARRAYI0..2] OF Menu; 

StatusWindow 

WindowPtr; 

StacusWinRPPtr 

RastPortPtr; 

Board 

ARRAY[1..64) OF Figtype; 

PotZug 

ARRAY16; 

Spieler 

Figtype; 

Rechner 

Figtype; 

AmZug 

Figtype; 

PutFig 

BOOLEAN; 

ToBeRemoved 

BOOLEAN; 


PROCEDÜRE Okay(text:ARRAY OF CHAR;acr:ADDRESS):BOOLEAK; 

(* meldet Fehler, falls Windows oder Bitmaps nicht korrekt 
eingerichtet werden können *) 

PROCEDÜRE SetCoiours; 

(* Farben-Handling *) 

PROCEDÜRE Dim3D; 

(♦ setzt Flag, sodaß Spielbrett in Rot-Grün-3D erscheint *) 
PROCEDÜRE Dim2D; 

( # setzt Flag, sodaß Spielbrett in perspektivischer 2-D-Ansicht 
erscheint •) 

PROCEDÜRE DrawBoard; 

(* zeichnet das komplette Spielbrett in 2-D- oder 3-D-Ansicht *) 
PROCEDÜRE DrawHiddenFigure(i:INTEGER;Typ:Figtype); 

{* zeichnet eine Kugel mit verdeckten Kanten ins Spielfeld *) 
PROCEDÜRE DrawHiddenFigureRM(i:INTEGER;Typ:Figtype); 

(* nimmt eine Kugel vom Brett *) 

PROCEDÜRE TypeFigure(Typ:Figtype); 

(* zeichnet eine Kugel der Farbe 'Figtype* ins Statusfenster, 
um anzuzeigen, wer am Zug ist *1 
PROCEDÜRE FigPicked(VAR BestZug:INTEGER):BOOLEAN; 

(* prüft, ob der menschl. Spieler Zug ausgeführt hat (TRUE) 
und gibt an, welcher Zug gewählt wurde (BestZug) ‘I 
PROCEDÜRE RotateBoard; 

(* führt die gewünschte Drehung der Spielbrettansicht aus *) 
PROCEDÜRE InitGame (! :BOOLEAN; 

{* initialisiert die Grafik *) 

PROCEDÜRE CioseDownGraph; 

(* gibt Speicher für die Bitmaps etc. zurück * 

END sogograph. © 1993 M&T 

Listing 2: »Sogograph.def« steuert die 
grafische Darstellung des Spiels 
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DEFINITION MODULE sogostrat; 

FROH sogograph IMPORT Figtype,ARRAY16; 
FROM Intuition IMPORT IDCMPFlagSet; 


TYPE MUEHLEN = ARRAY[1..76),[1..61 OF INTEGER; 
ZUEGE = ARRAY[1..64J,[1..20] OF INTEGER; 

Stat = ARRAYfl..8] OF INTEGER; 

CONST DiagBonus = 5; 

VAR 


MKL 


MUEHLEN; 
I* MHL[X][1..4]: 
I* MHL{X] [5] : 
(* MHL[X][6) : 
K : ZUEGE; 

(* ZK(yj[1] : 
(* ZK[YJ[2..8] : 
(*ZKlY]l9j : 
l* ZKIYI[10] : 
(* ZK(Y] [11] : 
(* ZKIYI[12] : 
I* ZK{Y] [13] : 


(* ZK{Y][14] : 

I* ZK[Y](15] : 

(* ZKIY][16] : 

(* ZK[Y][17] : 

(* ZK[Y] [18] : 

I* ZK[Y][19] : 

{* ZK[Y][20] : 

MHLStat : Stat, 


Kugelpositionen der Mühle Nr. X •) 
.Anzahl der weißen Kugeln in Mühle X *) 
Anzahl der schwarzen Kugeln in Mühle X *) 

Zahl der Mühlen, in denen Zug Y vorkönnt. *) 
Die Niauaem X der Mühlen, in denen Y verkannt *) 
frei *} 

Anzahl der Mühlen von Y mit 1 weißen Kugel * 
Anzahl der Mühlen von Y mit 2 weißen Kugeln * 
Anzahl der Mühlen von Y mit 3 weißen Kugeln * 
Anzahl der Mühlen von Y mit 4 weißen Kugeln * 
frei * 
Anzahl der Mühlen von Y mit 1 schwarzen Kugel*; 
Anzahl der Mühlen von Y mit 2 schw. Kugeln *) 
Anzahl der Mühlen von Y mit 3 schw. Kugeln •) 
Anzahl der Mühlen von Y mit 4 schw. Kugeln *) 
frei *| 
frei *) 


1* MHLStat enthält die Zahl der von jedem Spieler ausschließlich 
mit Kugeln seiner Farbe belegten Mühlen; 

MHLStat[i] : Zahl der Mühlen mit i weißen Kugeln, U1..4 

MHLStat[4+j] : Zahl der Mühlen mit j schw. Kugeln, j=l..4 *) 
depth : INTEGER; 

(* Im Menu festgelegte Suchtiefe *) 

vardepth : INTEGER; 

I* tatsächliche Suchtiefe; in den ersten Zügen 
ist vardepth = 1, egal wie depth gesetzt ist *) 

BestZug : INTEGER; 

(* Zug mit der besten Bewertung *) 

gesamtAnz,betaAnz,alphaAnz,mdn : LONGINT; 

I* Status-Infos *) 


Verl : Figtype; 

(* erhält Farbe d. Verlierers *) 

ZugListe : ARRAYfl..64] OF INTEGER? 

(* enthält die Zughistorie, wird benötigt beim Sichern eines 
Spiels und bei der Zugrücknahme *) 

ZLIndex : INTEGER; 

(* aktueller Index v. ZugListe *) 

interrupt,Statusinfo : BOOLEAN; 

dass : IDCMPFlagSet; 

code : CARDINAL; 

PROCEDÜRE SetStatusInfo(i:INTEGERI; 

(* normale (i=0) oder erweiterte (i=l) Statusanzeige *) 
PROCEDÜRE SetDepth(i:INTEGER); 

(* definiert die im Menü gewählte Suchtiefe *) 

PROCEDÜRE Zug(VAR wert:LONGINT; färbe:Figtype; 

Step .-INTEGER; alpba.beta: LONGINT; 

PotZugünSorted:ARRAY16); 

. (* sucht im Spielebaum den besten Zug *) 

PROCEDÜRE InitStrat; 

(* initialisiert die Variablen des Moduls sogostrat *) 

END sogostrat. © 1993 M&T 


»Listing 3: Sogostrat« - der »Kern der 
Künstlichen Intelligenz« des Spiels 


Läuft die Intuition-Menü-Oberfläche feh¬ 
lerfrei, kann man als nächstes die Dummy¬ 
prozedur von DrawBoard mit sinnvollem 
Programmcode füllen, sodaß der Aufruf die¬ 
ser Prozedur auch tatsächlich das gewünschte 
Spielbrett auf den Bildschirm zeichnet. 

Nach und nach arbeitet man sich so zum 
Kern zu den Strategieroutinen vor. Die härte¬ 
ste Nuß, die Programmierung der Prozedur 
für die Bewertung der willkürlichen Endstel¬ 
lungen, spart man sich bis ganz zuletzt auf. 
Diese Prozedur bestimmt wesentlich die 
Spielstärke und erfordert eine gründliche 
Spielanalyse. Wer ein Strategiespiel pro¬ 
grammieren will, sollte dieses Spiel sehr gut 


beherrschen. Man wird mit einfachen Bewer¬ 
tungskriterien beginnen und findet dann in 
vielen Testspielen gegen den Computer wei¬ 
tere Ansätze zur Optimierung der heuristi¬ 
schen Stellungsbewertung. Die bereits vor¬ 
handene Anwenderoberfläche mit einer über¬ 
sichtlichen Spielbrettdarstellung sowie den 
bereits implementierten Funktionen wie »Zug 
setzen«, »Zug zurücknehmen«, »Seitenwech¬ 
sel", »Spiel sichern«, »Spiel laden« sind eine 
unschätzbare Hilfe, weil man sich bei der 
Suche nach besseren Bewertungskriterien 
ganz auf das Spiel konzentrieren kann. 

Das SOGO-Programm mit allen Moduln 
umfaßt einige Tausend Zeilen Quellcode, so 
daß ein kompletter Abdruck nicht sinnvoll 
ist. Um Ihnen das Abtippen zu ersparen, ver¬ 
öffentlichen wir das lauffähige SOGO-Pro¬ 
gramm mit allen Quellcodes auf der PD-Dis- 
kette zu diesem Heft. Nur das Strategiemodul 
sogostrat.mod ist in Listing 4 abgedruckt. Es 
enthält Minimaxverfahren und alfa/beta-Pru- 
ning als Modula-2-Programmcode. 

Datenstrukturen: 

Beim Programmstart werden alle Varia¬ 
blen des Moduls sogostrat in der Prozedur 
InitStrat mit Anfangswerten belegt. Das 
Spielbrett ist durch das ARRAY Board dar¬ 
gestellt. Es enthält entsprechend den 64 mög¬ 
lichen Kugelpositionen 64 Elemente, die den 
Wert pin, black oder white annehmen kön¬ 
nen. ln Bild 10 und 11 trägt jede Kugelposi¬ 
tion die Nummer des zugehörigen ARRAY- 
Elementes. 

Die Mühlenstruktur des Spielbretts wird 
bei der Initialisierung der ARRAYs MHL 
und ZK festgelegt. MHL enthält für jede der 
insgesamt 76 möglichen Mühlen die 
zugehörigen 4 Kugelpositionen. Umgekehrt 
gibt ZK für jede der 64 Kugelpositionen an, 
in wieviel und in welchen der 76 möglichen 
Mühlen sie nthalten ist. Während des Spiels 
wird in MHL und ZK sowie MHLStat nach 
jedem Zug die Datenbasis für die Stellungs¬ 
bewertung auf den neuesten Stand gebracht. 

In MHL wird für jede der 76 möglichen 
Mühlen notiert, mit wieviel Kugeln jeder 
Spieler sie belegt hat. In ZK wird für jede 
Kugelposition eingetragen, wieviele der 
zugehörigen möglichen Mühlen jeder Spieler 
mit wieviel eigenen Kugeln beherrscht. Eine 
mögliche Mühle gilt dann als von einem 
Spieler beherrscht, wenn sie ausschließlich 
mit Kugeln seiner Farbe belegt ist. 

MHLStat enthält für beide Spieler die 
Gesamtanzahl der jeweils mit 1, 2, 3 oder 4 
Steinen beherrschten Mühlen. 

Minimax und alfa-beta 

Wenn der Amiga an der Reihe ist, sucht er 
mit der Prozedur Zug im SOGO-Spielbaum 
nach dem besten Zug. Die in der aktuellen 
Stellung möglichen Züge werden im Feld 
PotZugUnSorted an diese Prozedur überge¬ 
ben. Sie setzt eine Kugel probeweise aufs 
Spielbrett und ruft sich anschließend selbst 
erneut auf. Bis zu welcher Tiefe der Spiel¬ 
baum durch diese Rekursion entwickelt wird, 
bestimmt die Variable Step, die bei jedem 
Rekursionsschritt um 1 verringert wird. 


Ist Step = 0, wird anstelle eines weiteren 
Rekursionsschritts die erzeugte Stellung 
bewertet. In jeder Rekursionsstufe werden 
die von den folgenden Stufen zurückgeliefer¬ 
ten Werte mit dem Minimaxverfahren bear¬ 
beitet. Die alfa/beta-Bedingungen entschei¬ 
den, ob Probezüge gespart werden können. 

Auf der ersten Rekursionsstufe wird 
schließlich anhand des günstigsten, zurückge¬ 
lieferten Wertes der beste Zug für die aktu¬ 
elle Stellung bestimmt. 



Bild 10: Weiß ist am Zug. Es besteht 
Kreuzmühlengefahr für Weiß. Wenn 
Weiß nicht eine der schwarzen 
Mühlen (1,5,9,13) oder (5,21,37,53) 
blockiert, kann Schwarz im Gegenzug 
Position 5 besetzen. Der Gewinn von 
Schwarz ist dann nicht aufzuhalten. 

Um das alfa/beta-Pruning effektiv zu 
machen, werden die möglichen Züge vor 
jedem weiteren Rekursionsschritt mit der 
Prozedur SortPotZug sortiert. Wenn ein Spie¬ 
ler eine Mühle bereits mit mehreren Kugeln 
beherrscht, wird er versuchen, diese Mühle 
weiter auszubauen, um schließlich mit der 
vierten Kugel seine Mühle zu vollenden und 
zu gewinnen. Andererseits wird sein Gegen¬ 
spieler alles tun, um das zu verhindern. Er 
wird ebenfalls eine Kugel in der vom Gegner 
beherrschten Mühle plazieren wollen, um 
dessen Gewinn zu verhindern. Es ist also 
wahrscheinlich, daß ein Zug, der zu einer mit 
bereits vielen Kugeln beherrschten Mühle 
gehört, der beste Zug in einer Stellung ist. 

Wenn man die in einer Stellung möglichen 
Züge entsprechend sortiert, kann man den 
Zug mit der voraussichtlich besten Bewer¬ 
tung zuerst ausprobieren. Oft werden dann 
bereits im ersten Probezug die alfa- oder 
beta-Bedingung erfüllt und die restlichen 
Züge brauchen nicht überprüft zu werden. 

Bewertungskriterien 

Der Amiga kann den SOGO-Spielbaum in 
erträglicher Zeit auch bei alfa/beta-Pruning 
nur etwa 7 Züge tief durchsuchen. Für die in 
dieser Tiefe angetroffenen willkürlichen End¬ 
stellungen müssen Bewertungskriterien for¬ 
muliert werden. Ziel ist, jeder Stellung eine 
Zahl zuzuordnen, die ihren Wert wiedergibt. 

Die Prozedur BEWERTUNG untersucht 
zuerst das Spielbrett auf bestimmte Stellungs¬ 
muster. Dabei wird z.B. festgestellt, ob 
Kreuzmühlengefahr (Bild 10) besteht, eine 
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Doppeldrohung (Bild 11) aufgebaut wird 
oder im nächsten Zug eine Mühle vollendet 
werden kann. Für insgesamt 20 Kriterien die¬ 
ser Art wird geprüft, wie oft sie in der zu 
bewertenden Stellung erfüllt sind. 



Bild 11: Eine Doppeldrohung gegen 
Schwarz. Um die Lage zu entschärfen, 
muß Schwarz eine Kugel auf Position 
21 setzen. Könnte Weiß die Position 
besetzen, würden die Mühlen (5,21, 
37,53) und (33,38,43,48) mit je drei 
Kugeln von Weiß beherrscht. Die feh¬ 
lenden vierten Kugeln 37 und 38 lie¬ 
gen übereinander. Wenn Schwarz mit 
einer Kugel an Position 37 die untere 
Mühle verhindert, kann Weiß die 
obere vervollständigen. 

Die den verschiedenen Kriterien zugehöri¬ 
gen Häufigkeiten werden in den ARRAYS 
ZugStat bzw. MHLStat gespeichert. Der end¬ 
gültige Wert einer Stellung ist die gewichtete 
Summe der Häufigkeiten. Durch die Gewich¬ 
tung wird der unterschiedlichen Bedeutung 
der Kriterien Rechnung getragen. Die Fakto¬ 
ren sind im ARRAY GEWICHT gespeichert. 

Die Prozedur BEWERTUNG liefert für 
eindeutige Gewinnpositionen sehr große po¬ 
sitive Werte, ausgeglichene Stellungen erhal¬ 
ten Werte um 0 und Verlustpositionen wer¬ 
den extrem negative Werte zugewiesen. 

Spielprogramme mit heuristischen Bewer¬ 
tungskriterien werden eigentlich nie fertig. 
Obwohl SOGO in der vorliegenden Version 
eine passable Spielstärke besitzt, gibt es Ver¬ 
besserungsansätze: Man könnte mit einer 
Evolutionsstrategie die Künstliche Intelligenz 
sogar dazu bringen, sich selbst zu optimieren, 
indem man den Amiga z.B. die Auswirkung 
zufälliger Mutationen am ARRAY GE¬ 
WICHT untersuchen läßt. 

Dazu läßt man den Amiga 100 Partien 
gegen sich selbst spielen. Als Spieler 1 ver¬ 
wendet er das mutierte ARRAY, als Spieler 2 
das ursprüngliche. Das ARRAY des Gewin¬ 
ners überlebt und ist Ausgangsbasis für neue 
Mutationen. Wenn man dem AMIGA nur 
genügend Zeit läßt, wird er irgendwann ein¬ 
mal als Spieler 1 gewinnen und damit eine 
Verbesserung für das ARRAY GEWICHT 
gefunden haben. Ein Tip für den, der es pro¬ 
bieren will: Elemente für eine Erfolg verspre¬ 
chende Mutation sind: GEWICHT[8..10] und 
GEWICHT[ 18..20]. ub 


IMPLEMENTATION MODULS sogostrat; 

I* Legt allgemeine Suchtiefe und Bewertungsgewichte fest *) 

FROM SYSTEM IMPORT ADR,LONGSET; 

BEGIN 




FROM Intuition IMPORT IntuiMessagePtr,IntuiText,IDCMPFlagSet; 

gewicht[1] 

= 

10000000 


FROM Exec IMPORT SetSignal,GetMsg,ReplyMsg; 

gewicht[2] 

r 

900000 


FROM InOut IMPORT Writelnt,WriteLn,WriteString; 

gewicht[3] 

= 

80000 


FROM Conversions IMPORT ValToStr; 

gewicht[4] 

= 

800000 


FROM Str IMPORT Length; 

gewicht[5] 

= 

20000 


FROM RandomNumber IMPORT RND; 

gewicht[6] 

= 

500000 


FROM Graphics IMPORT SetAPen,Draw,Move,Text,jaul; 

gewicht[7] 

= 

90000 


FROM sogograph IMPORT Figtype,Board,AmZug,SpielWinRPPtr, 

gewicht]8] 

= 

3 


SpielWindowPtr, 

gewicht]9] 

= 

4 


StatusWinRPPtr,StatusWindow,ARRAYI6; 

gewicht]10]: 

= 5 


VAR S10 : ARRAY[1..10] OF CHAR; 

gewicht]11]: 

= 0 


err : B00LEAN; 

gewicht[12]: 

=- 700000 


IntuiMsg : IntuiMessagePtr; 

gewicht[13]: 

=- 1000 


gewicht : ARRAY[1..20] 0F L0NGINT; 

gewicht]14]: 

=- 18000 


PROCEDURE SortPotZugIVAR 

gewicht[15]: 

=- 5000 


PotZugSorted;ARRAY16;PotZugUnSorted:ARRAY16); 

gewicht[16]: 

=- 16000 


(* sortiert die möglichen Züge, sodaß das alfa/beta- *) 

gewicht]17]: 

=- 500 


(* Pruning effektiver wird; *) 

gewicht]18]: 

=- 3 


(* Sortierkriterium: Je weiter die zu einen Zug gehörenden 

gewicht]19): 

=- 4 


Mühlen*) 

gewicht[20]: 

=- 5 


(* ausgebaut sind, um so eher wird dieser Zug untersucht. *) 

depth:=i; 




VAR i.j.k.m :INTEGER; 

IF (i=0) THEN 


PotZuglndex :ARRAY[1..16] 0F INTEGER; (* enthält Bewertung 

gewicht]!]:= 10000000; 

der 

gewicht[2]: 

= 

; 

potentiellenZüge entsprechend Sortierkriterium *) 

gewicht[3]: 

= 

; 

BEGIN 

gewicht[4] 

= 80000C 

; 

F0R i:=l TO 16 DO 

gewicht]5]: 

= 0; 


PotZuglndex[i]:=0; 

gewicht]6]: 

= 0; 


PotZugSorted[i]:=PotZugünSorted(i]; 

gewicht]7]: 

= 0; 


END; 

gewicht ]8]: 

= 

; 

(* Bewertung der Züge nach Sortierkriterium *) 

gewicht]9]: 

= 


F0R i;=1 TO 16 DO 

gewicht[10; 

:= 


IF PotZugUnSorted]i]>0 THEN 

gewicht]11] 

:=- 

; 

F0R j:=2 T0 ZK[PotZugUnSorted[i] J.[l]+1 DO 

gewicht[12; 

: = - 

; 

k:=ZK[PotZugUnSorted[i]][j]; 

gewicht[13; 

:=- 

j 

IF (MHL[k](5]=0) 0R ]MHL[k][6]=0) THEN 

gewicht[14] 

:=- 1800C 

; ' 

IF (MHL(k][5]=3) 0R (MHl[k] [6] =3) THEN 

gewicht[15! 

:=- 0; 


PotZuglndex[i]:=PotZugIndex ti]+5000; 

gewicht[16! 

:=- 0; 


ELSE 

gewicht[17; 

:=- 0; 


IF lMHL[k][5]=2) 0R (MHL[k]]6]=2) THEN 

gewicht[18; 

:=- 

; 

PotZuglndex(i]:=PotZugIndex[i]+500; 

gewicht[19; 

:=- 

; 

ELSE 

gewicht[20; 



IF (MHL[k][5]=l) OR (MHL[k](6]=l) THEN 

END; 




PotZuglndex[i]:=PotZuglndex[i]+20; 

END SetDepth; 



ELSE 

PROCEDURE Bewertung(färbe :Figtype;PotZug:ARRAY16):L0NGINT; 

IF (MHL[k][5]=0) AND (MHL(k]]6]=0) THEN 

(* führt die Bewertung einer willkürlichen Endstellung durch.*) 

PotZuglndex[i]:=PotZugIndex[i]+1; 

(* färbe : gibt am Zug befindlichen Spieler an, aus dessen Sicht *) 

END; 

(* die Bewertung durchgeführt werden soll. *) 

END; 

(* PotZug: die in der zu bewertender, Stellung möglichen Züge *) 

END; 

(* RETURN: wert: LQNGINT-Wert gibt den Stellungswert an *) 

END; 

VAR Hl,H2,i,j, 

k,m,n,p,q 

:INTEGER; (* Hilfs- und Laufvariablen *) 

END; 

wert : 

LONGINT; (* 

Stellungsbewertung *) 

END;(* of FOR *) 

ZugNr,ZugNrUp,ZugNrüpUp :INTEGER; (* Nummern von 3 

END; <• of IF *) 

übereinander 




END;(* of FOR *) 




liegenden Kugelpositionen *) 

(* SHELL-Sort von PotZugUnSorted in PotZugSorted *) 

ZKME,ZKYOU,ME,YOU :INTEGER; {* Indexoffsets für ZK und MHL *) 

k:= 8; 

MEMSInd,YOUMSInd :INTEGER; (* Indexoffset für MHLStat *) 

WHILE (k>0) DO 

ZugStat 


:ARRAY[1..17] OF INTEGER; 

i:=k; 

(* Jedes Feldelement von ZugStat entspricht einem Bewertungskriterium. 

WHILE (i<16) DO 

Ist es erfüllt, wird das Element inkrementiert. Sind alle 

j:=i-k; 

3ewertungskriterien überprüft, ergibt die gewichtete Addition 

WHILE ( j>=0) AND (PotZuglndex[j+1] < PotZuglndex]j+k+1]) DO 

der Elemente von ZugStat die Stellungsbewertung. *) 

m:= PotZuglndex]j+1]; 

PotDDUp.PotDDDown :B00LEAN; (* Flags, die beim Erkennen einer *) 

Pot ZugIndex(j+1]:=PotZugIndex[j+k+1]; 

PotPotDDUp,PotPotDDDcwn :B0OLEAN; (‘Doppeldrohung gesetzt werden*) 

PotZuglndex!j+k+1]:=m; 

Damokles 


:B00LEAN 

(* Flag wird gesetzt, wenn im 

m:=PotZugSorted l j+1]; 




Gegenzug Spielverlust droht *) 

PotZugSorted]j+1]:=PotZugSorted[j+k+1]; 

BEGIN 




PotZugSorted]j+k+1]:=m; 

(* Infos für das Status-Window *) 

j:=j~k; 

INC(gesamtAnz); 


END; 

IF Statusinfo THEN 


i:=i+l; 

IF gesamtAnz MOD 8 

= 0 THEN 

END; 

ValToStr(gesamtAnz,FALSE,S10,10,8,' *,err); 

k:=k DIV 2; 

MovetStatusWinRPPtr,80,75); 

END; 

Text(StatusWinRPPtr,ADR(S10),LengthIS10) ); 

END SortPotZug; 

END; 




PROCEDURE SetStatusInfoU:INTEGER); 

END; 




(* setzt (i=l) oder löscht (i=0) das Statuslnfo-Flag, das die An¬ 

(* Initialisieren *) 


zeige von Spielstatus-Informationen im Status-Window steuert *) 

wert : =0 ; 




BEGIN 

FOR i:=l TO 17 DO ZugStat[i ] :=0; END; 

IF i=0 THEN Statusinfo:=FALSE ELSE Statusinfo:=TRUE END; 

(* Indexoffsets festlegen *) 

END SetStatusInfo; 

IF (färbe 


white) THEN 

PROCEDURE SetDepth ( i : INTEGER ); 
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ME:=5; Y0U:=6; ZKME:=10; ZKY0U:=15; MEMSInd:=l; Y0üMSInd:=5; 
ELSE 

END; 

END; 

ME:=6; Y0ü:=5; ZKME:=15; ZKYOU:=10; MEMSInd:=5; YOUMSInd:=l; 

END; 

IF ((H2-1) MOD 4) >0 THEN 

END; 

{*4. Stein in ME-MHL setzbar: ME gewinnt *) 

IF ZK[H2-1][ZKYOU+2]>0 THEN 

1* Hauptschleife: Auswirkungen der Folgezüge prüfen *) 

IF ZK[ZugNr][ZKME+2]>0 THEN 

PotPotDDDown:=TRUE; 

FOR i:=1 TO 16 DO 

INC(ZugStat[1]); 

END; 

(* Feststellen, ob Kreuzmühlengefahr oder Doppeldrohung vorliegt 

END; 

END; 

*) 

(‘ Doppeldrohung zu Spielgewinn wandelbar: ME gewinnt ‘) 

END; 

ZugNr:=PotZug[i]; 

IF ZugNrUp>0 THEN 

END; 

(* Writelnt(ZugNr,4);*) 

IF ZugNrUpUp>0 THEN 

END; 

IF ZugNr>0 THEN 

IF (ZK[ZugNrUp][ZKME+2]>0) THEN 

END; 

IF ZugNr MOD 4 > 0 THEN 

IF (ZK[ZugNrüpüp][ZKME+2]>0) THEN 

END; 

ZugNrüp:=ZugNr+l; 

INC(ZugStat[2]); 

END; 

ELSE 

END; 

END? 

ZugNrUp:=0; 

END; 

DEC(m); 

END; 

END; 

Damokles:=FALSE; 

IF ZugNrüp MOD 4 > 0 THEN 

END; 

IF ZugNrUp>0 THEN 

ZugNrüpüp:=ZugNr(Jp+1; 

IF NOT Damokles THEN 

IF ZK[ZugNrUp][ZKME+2]>0 THEN 

ELSE 

(* Kreuzungsstein in ME-MHL mit je 2 Steinen setzbar *) 

Damokles:=TRUE; 

ZugNrUplfp: =0; 

IF (ZK[ZugNrj[ZKME+1]>1) THEN 

END; 

END; 

INC(ZugStat[3]); 

END; 

Pot DDÜp:= FALSE;Pot DDDown:=FALSE; 

(* Kreuzungsstein in ME-MHL mit je 2 Steinen setzbar; in beiden 

(* 4. Stein in YOU-MHL setzbar: YOU erzeugt Zugzwang für ME *) 

PotPotDDUp:=FALSE;PotPotDDDown:=FALSE; 

MHL 

IF ZK[ZugNr][ZKYOU+2]>0 THEN 

IF (ZK(ZugNr)[ZKME]>0) OR (ZK[ZugNr)[ZKME+1]>0) THEN 

kann im nächsten Zug der 4. Stein gesetzt werden: ME gewinnt ♦) 

INC(ZugStat[11]); 

Hl:=ZK[ZugNr][1]+1; 

IF (m>l) THEN 

END; 

m:=l; 

INC(ZugStat[4]); 

(* Doppeldrohung zu Spielgewinn wandelbar: YOU gewinnt ♦) 

FOR j:=2 TO Hl DO 

END; 

IF ZugNrUp>0 THEN 

IF MHL[ZK[ZugNr][j]]IME]=2 THEN 

END; 

IF (ZK[ZugNrUp][ZKYOU+2]>0) THEN 

IF MHL[ZK[ZugNr][j]][YOU]=0 THEN 

(* mit 2. Stein in ME-MHL Doppeldrohung gegen YOU vorbereiten *) 

IF (ZK[ZugNr][ZKYOU+2]>0) THEN 

FOR k:=l TO 4 DO 

IF PotPotDDUp OR PotPotDDDown THEN 

INC(ZugStat[12]); 

H2 := MHL[ZK[ZugNr][j]][k]; 

INC(ZugStat[5]1; 

END; 

IF (Board[H2]=pin) AND (H2#ZugNr) THEN 

END; 

END; 

FOR n:=l TO 16 DO 

(* mit 3.Stein in ME-MHL Doppeldrohung gegen YOU möglich *) 

END; 

IF PotZug[n]=H2 THEN 

IF PotDDüp OR PotDDDown THEN 

IF NOT Damokles THEN 

INC(m); 

INC(ZugStat [6] }; 

<* Kreuzungsstein in YOU-MHL mit je 2 Steinen setzbar ♦) 

END; 

END; 

IF (ZK[ZugNr][ZKYOU*l]>l) THEN 

END; 

{* Stein in der Kreuzung von mehr als 1 ler-MEMHL und 1 2er MEMHL 

INC(ZugStat[13]»; 

IF ZK[ZugNr][j]>16 THEN 

‘) 

I* Kreuzungsstein in YOU-MHL mit je 2 Steinen setzbar; in beiden MHL 

IF H2 MOD 4 >0 THEN 

IF (ZK[ZugNr][ZKME]>l) AND (ZK[ZugNr][ZKME+1]>0> THEN 

kann im nächsten Zug der 4. Stein gesetzt werden: Zugzwang *) 

IF ZK[H2+1][ZKME+2]>0 THEN 

INC(ZugStat[7]) ; 

IF (m>l) THEN 

PotDDüp:=TRUE; 

END; 

INC(ZugStat[14])? 

END; 

END; 

END; 

END; 

<* Dasselbe für YOU-MHL *) 

END; 

IF ((H2-1) MOD 4) >0 THEN 

PotDDUp:=FALSE;PotDDDown:=FALSE; 

(* mit 2. Stein in YOU-MHL Doppeldrohung gegen ME vorbereiten *) 

IF ZK[H2-1][ZKME+2]>0 THEN 

PotPotDDUp:=FALSE;PotPotDDDown:=FALSE; 

{* IF PotPotDDUp OR PotPotDDDown THEN *) 

PotDDDown:=TRUE; 

IF (ZK[ZugNr][ZKYOU]>0) OR (ZK[ZugNr][ZKYOU+1]>0) THEN 

IF PotDDUp OR PotDDDown THEN 

END; 

Hl:=ZK[ZugNr][1]+1; 

INC(ZugStat[15J1; 

END; 

m:=l; 

END; 

END; 

FOR j:=2 TO Hl DO 

(* mit 3. Stein in YOU-MHL Doppeldrohung gegen YOU möglich *) 

END; 

IF MHL[ZK[ZugNr][j]][YOU]=2 THEN 

(* IF PotDDUp OR PotDDDown THEN *) 

END; 

IF MHL[ZK[ZugNr][j]][ME]=0 THEN 

IF ZugNrUp>0 THEN 

END; 

FOR k:=l TO 4 DO 

IF ZugNrUpUp>0 THEN 

END; 

H2 := MHL[ZK[ZugNr][j]][k]; 

IF (ZK[ZugNrUp][ZKYOU+2]>0) THEN 

IF ZK[ZugNr][j)>16 THEN 

IF (Board[H2]=pin) AND (H2IZugNr) THEN 

IF (ZK [ ZugNrüpüp ] (ZKYOU+2 ] >0) THEN 

IF MHL[ZK[ZugNr][j]][ME]=1 THEN 

FOR n:=l TO 16 DO 

INC(ZugStat[16]); 

IF MHL[ZK[ZugNrj[j]][YOU]=0 THEN 

IF PotZugln]=H2 THEN 

END; 

FOR k:=l TO 4 DO 

INC(m); 

END; 

H2 := MHL[ZK|ZugNr][j]] [k] ; 

END; 

END; 

IF (Board[H2]=pin) AND {H2#ZugNr) THEN 

END; 

END; 

IF H2 MOD 4 >0 THEN 

IF ZK[ZugNr][j]>16 THEN 

(* Stein in der Kreuzung von mehr als 1 ler-YOUMHL und 1 2er YOUMHL*) 

IF ZK[H2+1][ZKME+2]>0 THEN 

IF H2 MOD 4 >0 THEN 

IF (ZK[ZugNr][ZKYOU]>1) AND (ZK[ZugNr][ZKYOU+1]>0) THEN 

PotPotDDUp:=TRUE; 

IF ZK[H2+1][ZKYOU+2]>0 THEN 

INC(ZugStat[17]); 

END; 

PotDDUp:=TRUE; 

END; 

END; 

END; 

END;(*of Damokles *) 

IF ((H2-1) MOD 4) >0 THEN 

END; 

END;(* of ZugNr>0 *) 

IF ZK[H2-1][ZKME+2]>0 THEN 

IF ((H2-1) MOD 4) >0 THEN 

END;(* of FOR *) 

PotPotDDDown:=TRUE; 

IF ZK[H2-1][ZKYOU+2]>0 THEN 

wert:= 

END; 

PotDDDown:=TRUE; 

gewicht[1]‘LONGINT(ZugStat[1]) gewicht[2]‘LONGINT(ZugStat[2]) 

END; 

END; 

♦gewicht[3]*LONGINT(ZugStat[3]) ♦gewicht[4]*LONGINT(ZugStat[4]) 

END; 

END; 

♦gewicht[5]*LONGINT(ZugStat[5]) +gewicht[6]* LONGINT(ZugStat[6]) 

END; 

END; 

♦gewicht [7] *LCN3INT( ZugStat [7]) +gewicht [8] ‘LONGINT (MHLStat [MEMSInd]) 

END; 

END; 

♦gewicht[9]‘LONGINT(MHLStat[MEMSInd+1]) 

END; 

END? 

♦gewicht[10]‘LONGINT(MHLStat[MEMSInd+2]) 

END; 

END; 

♦gewicht[11]‘LONGINT (ZugStat[11]) ♦gewicht[12]‘LONGINT(ZugStat[12]( 

END; 

END; 

♦gewicht[13]»LONGINT(ZugStat[13]) +gewicht[14]‘LONGINT (ZugStat[14]) 

END; 

IF ZK[ZugNr][j]>16 THEN 

♦gewicht[15]‘LONGINT (ZugStat[15]) +gewicht[16]‘LONGINT (ZugStat[16]) 

DEC(m); 

IF MHL[ZK[ZugNr] [j]] [YOU]=l THEN 

♦gewicht[17]‘LONGINT (ZugStat[17]) 

(* Ist die in der Position oberhalb von ZugNr liegende Kugel die 

IF MHL[ZK[ZugNr][j]][ME]=0 THEN 

♦gewicht[18]‘LONGINT(MHLStat[YOUMSInd]) 

4. 

FOR k: =1 TO 4 DO 

♦gewicht[19]‘LONGINT(MHLStat[YOUMSInd+1]) 

in einer Mühle des Gegenspielers, sodaß er im Gegenzug gewinnt? 

H2 := MHL[ZK[ZugNr][j]][k]; 

♦gewicht[20]*LONGINT(MHLStat[YOUMSInd+2]); 

*1 

IF (Board[H2]=pin] AND (H2#ZugNr) THEN 

(* WriteLn; 

Damokles:=FALSE; 

IF H2 MOD 4 >0 THEN 

FOR i:=l TO 17 DO Writelnt(ZugStat[i],3); END; 

IF ZugNrUp>0 THEN 

IF ZK[H2+1][ZKYOU+2]>0 THEN 

Writelnt(wert,10); 

IF ZKlZugNrUp][ZKYOÜ+2]>0 THEN 

PotPotDDUp:=TRUE; 


Damokles:=TRUE; 

END; 
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GRUNDLAGEN 


WriteLn; 

CASE MHL[n][ME] OF 

IF (MHL[n][ME]=1} AND (MHL[n][YOU]>0) THEN 

FOR i:=l TO 8 DO Writelnt(MHLStat[i],3); END; 

, 1: INC(MHLStat[MEMSInd],Increment); 

CASE MHL[n][YOU] OF 

WriteLn; *} 

FOR j:=l TO 4 DO 

1: INC(MHLStat[YOUMSInd],Increment); 

RETURN(wert); 

INC(ZK[MHL[n][j]][ZKME]); 

FOR j:=l TO 4 DO 

END Bewertung; 

END; 1 

INC|ZK(MHL[n][j]][ZKYOU]); 

PROCEDURE Zug(VAR 

2: INC(MHLStat[MEMSInd+1],Increment); 

END; 1 

wert:LONGINT;färbe;Figtype;Step:INTEGER;alpha,beta: LONGINT; 

DEC(MHLStat[MEMSInd],Increment); 

2: INC(MHLStat[YOUMSInd+1],Increment); 

PotZugUnSorted:ARRAY16); 

FOR j:=1 TO 4 DO 

FOR j:=l TO 4 DC 

(* Rekursive Prozedur mit Minimaxverfahren und alfa/beta-Pruning *) 

INC(ZK[MHL[n]lj]][ZKME+1)); 

INC(ZK[MHL[n][j]][ZKYOU+1]); 

(* wert: Bewertung des Knotens, an dem Proz. Zug aufgerufen wurde*) 

DEC(ZK(MHL[n][j]][ZKME]); 

END; | 

(* färbe: Farbe des Spielers, der im aufrufenden Knoten am Zug ist*) 

END; | 

3: INC(MHLStat[YOUMSInd+2],Increment); 

(* step: Suchtiefe *) 

3: INC(MHLStat[MEMSInd+2],Increment); 

FOR j:=l TO 4 DO 

(* alfa.beta: Schwellwerte für die alfa/beta-Abbruchbedingungen *) 

DEC(MHLStat[MEMSInd+1],Increment); 

INC(ZK[MHL[n][jj][ZKYOU+2]); 

(* PotZugUnSorted: die am aufrufenden Knoten möglichen Folgezüge *) 

FOR j:=l TO 4 DO 

END; 1 

VAR i,j,k,m,n,p :INTEGER; (* Laufvariablen *) 

INC(ZK[MHL[n][j]][ZKME+2]); 

4: INC(MHLStat[YOUMSInd+3],IncrementI; 

Gegenfarbe :Figtype; 

DEC(ZK[MHL[n][j)l[ZKME+1]); 

FOR j:=l TO 4 DO 

zbZug :INTEGER; (* Position des gerade ausprobierten Zugs *) 

END; | 

INC(ZK[MHL[n][j]][ZKYOU+3]); 

aktZug :LONGINT; (* Wert der Stellung,zu der dieser Zug führt*) 

4: INC(MHLStat[MEMSInd43],Increment); 

END; 1 

maxZug :LONGINT; (* Wert der bisher besten Stellung *) 

DEC(MHLStat[MEMSInd+2].Increment); 

ELSE END; 

YOU,ME,ZKYOU.ZKME:INTEGER;!* Indexoffsets *) 

FOR j:=l TO 4 DO 

END; 

MEMSInd.YOUMSInd:INTEGER; (* Indexoffsets *) 

INCIZK[MHL[n][j]][ZKME+3]); 

DEC (MHL [n] [ME]); _ 

ex :B00LEAN; (* Flag für Abbruchssteuerung *) 

DEC(ZK[MHL[n][j]][ZKME+2]); 

END; 

PotZugSorted :ARRAY16; (* die vorsortierten möglichen Züge *) 

END; 1 

* Minimaxverfahren für max-Knoten *) 

Increment :INTEGER; (* Incr für MHLStat, abhängig davon, ob 

ELSE END; 

IF (AmZug = färbe) THEN 

Diagonalmühle vorliegt oder nicht *) 

END; 

IF (aktZug > maxZug) THEN 

BEGIN 

IF (MHL[n][ME]=1| AND (MHL[n][YOU]>0) THEN 

maxZug:=aktZug; 

(* Indexoffsets festlegen *) 

CASE MHL[n][YOU] OF 

IF (step = vardepth) THEN 

IF farbe=white THEN 

1: DEC(MHLStat[YOUMSInd],Increment); 

BestZug:=zbZug; 

Gegenfärbe:=black; 

FOR j:=l TO 4 DO 

END; 

YOU:=6;ME:=5;ZKME:=10;ZKYOU:=15;MEMSInd:=1;YOUMSInd:=5; 

DEC(ZK[MHL[n][j]][ZKYOU]); 

END; 

ELSE 

END; | 

IF (aktZug = maxZug) AND (RND(2) = 1) THEN 

Gegenfarbe:=white; 

2: DEC (MHLStat [ YO(JMSInd+1 ], Increment); 

maxZug:=aktZug; 

YOU:=5;ME:=6;ZKME:=15;ZKYOU:=10;MEMSInd:=5;YOUMSInd:=1; 

FOR j:=l TO 4 DO 

IF (step = vardepth) THEN 

END; 

DEC(ZK[MHL[n][j]][ZKYOU+1]); 

BestZug:=zbZug; 

IF step>0 THEN 

END; 1 

END; 

IF AmZug=farbe THEN maxZug:=-2000000000 (* max-Knoten *) 

3: DEC(MHLStat[YOUMSInd+2],Increment); 

END; 1* beta-Pruning an max-Knoten *) 

ELSE maxZug:= 2000000000;END; (* min-Knoten *) 

FOR j:=l TO 4 DO 

IF (maxZug > alpha) THEN alpha:=maxZug;END; 

ex:=FALSE; 

DEC(ZK[MHL[n][j)][ZKYOU+2]); 

IF (step * vardepth) AND (maxZug > beta) THEN 

SortPotZug(PotZugSorted,PotZugUnSorted); 

END; I 

betaAnz:=betaAnz+l; 

i: =0; 

4: DEC(MHLStat[YOUMSInd+3],IncrementI; 

IF Statusinfo THEN 

(* Züge zu den Folgestellungen ausführen *) 

FOR j:=1 TO 4 DO 

ValToStr(betaAnz,FALSE,S10,10,8,' \err); 

WHILE i<16 DO 

DEC(ZK[MHL[n][j]][ZKYOU+3]); 

Move(StatusWinRPPtr,80,65); 

INC(i); 

END; 1 

Text(StatusWinRPPtr,ADR(SIO),Length(SlO)); 

(* Statusbalken zeichnen *) 

ELSE END; 

END; 

IF Statusinfo THEN 

END; 

i:=17; 

SetAPen(StatusWinRPPtr,0)? 

END; 

END; 

Move(StatusWinRPPtr,2,10-step); 

(* rekursiver Aufruf *) 

ELSE 

Draw(StatusWinRPPtr,146,10-step); 

IF NOT((aktZug = 30000000) OR (aktZug = -30000000)) THEN 

(* Minimaxverfahren an min-Knoten *) 

SetAPen(StatusWinRPPtr, 9); 

Zug(aktZug,Gegenfarbe,step-1,alpha,beta,PotZugSorted); 

IF (aktZug < maxZug) THEN 

Move(StatusWinRPPtr,2,10-step); 

END; 

maxZug:=aktZug; 

Draw(StatusWinRPPtr,2+i*9,10-step); 

l* Board zurücksetzen und Änderungen in MHL und ZK zurücknehmen *) 

IF (step = vardepth) THEN 

END; 

Board[zbZug]:=pin; 

BestZug:=zbZug; 

aktZug:=0; 

PotZugSortedfi]:=zbZug; 

END; 

zbZug::PotZugSorted(i); 

FOR m:=2 TO p DO 

END; 

IF zbZug>0 THEN 

n:=ZK[zbZug][m]; 

IF (aktZug = maxZug) AND (RNDI2) = 1) THEN 

(* Board setzen und MHL und ZK aktualisieren *) 

IF ln>56) THEN Increment:=DiagBonus ELSE Increment:=1 

maxZug:=aktZug; 

Board[zbZug]:=farbe; 

END; 

IF (step = vardepth) THEN 

IF zbZug MOD 4 > 0 THEN 

IF (MHL[n][YOU]=0) THEN 

BestZug:=zbZug; 

INC(PotZugSorted]i]); 

CASE MHL[n][ME] OF 

END; 

ELSE 

1: DEC(MHLStat[MEMSInd],Increment); 

END; 

PotZugSorted[i]:=Q; 

FOR j:=l TO 4 DO 

I* alfa-Pruning an min-Knoten *) 

END; 

DEC(ZK[MHL[n][j1][ZKME]); 

IF (maxZug < beta) THEN beta:=maxZug;END; 

p:=ZK[zbZug][11+1; 

END; I 

IF (step 1 vardepth) AND (maxZug < alpha) THEN 

FOR m:=2 TO p DO 

2: DEC(MHLStat[MEMSInd+1],Increment); 

alphaAnz:=alphaAnz+l; 

n:=ZK[zbZug]Im]; 

INC(MHLStat[MEMSInd],Increment); 

IF Statusinfo THEN 

IF (n>56) THEN Increment:=DiagBonus ELSE Increment:=l END; 

FOR j:=l TO 4 DO 

ValToStr(aIphaAnz,FALSE,S10,10,8," ’,err); 

IF (MHL[n][YOU]=3) THEN 

DEC(ZK[MHL[n][j]][ZKME+1J); 

Move(StatusWinRPPtr,80,55); 

IF (MHL[n][ME]=0) THEN 

INC(ZK[MHL[n] [j]] [ZKME]); 


IF (step=vardepth) THEN vardepth:=l END; 

END; | 

Text(StatusWinRPPtr,ADR(S10).Length(SlO)); 

step;=l; 

3: DEC(MHLStat[MEMSInd+2],Increment); 

END; 

END; 

INC(MHLStat[MEMSInd+1],Increment); 

i:=17; 

END; 

FOR j:=l TO 4 DO 

END; 

INC(MHL[n][ME]); 

DEC(ZK[MHL[n][j]][ZKME+2]); 

END; 

IF lMHL[n][YOU]=0) THEN 

INC(ZK[MHLin][j]l[ZKME+1]); 

END;(* of IF *) 

IF MHL[n][ME]=4 THEN 

END; 1 

IF (SpielWindowPtr t NIL) THEN 

ex:=TRUE; 

4: DEC(MHLStat[MEMSInd+3],Increment); 

IntuiMsg:=GetMsg(SpielWindowPtr*.userPort); 

IF AmZug=farbe THEN 

INC(MHLStat[MEMSInd+2],Increment); 

IF IntuiMsg » NIL THEN 

aktZug:=30000000; 

FOR j:=l TO 4 DO 

dass :=IntuiMsg*. dass; 

ELSE 

DEC(ZK[MHL[n][j]][ZKME+3]); 

code :=IntuiMsg*.code; 

aktZug:=-30000000; 

INC(ZK[MHL[n][j]][ZKME+2]); 

ReplyMsg(IntuiMsg); 

END; 

END; 1 

interrupt := TRUE; 

END; 

ELSE END; 

END; 


END; 

END; 
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IF ex OR interrupt THEN 
i:=17; 

END; 

END;{* of WHILE *) 

ELSE (* Bewertung der willkürlichen Endstellungen *) 

IF AmZug=farbe THEN maxZug:=Bewertung(färbe,PotZugUnSorted) ; 

ELSE maxZug:=-Bewertung(farbe,PotZugUnSorted); 
EIL¬ 
END; 

wert: maxZug; 

END Zug; 

PROCEDURE InitStrat; initialisiert die Variablen ♦) 

VAR i,j : INTEGER; 

BEGIN 
Verl:=pin; 
interrupt:=FALSE; 

FOR i:=l TO 64 DO 
ZugListe[i):=0; 

FOR j:=9 TO 10 DO 
ZK[i][j]:=0; 

END; 

END; 

ZLIndex:=0; 

FOR i:=l TO 64 DO 
FOR j:=9 TO 20 DO 
ZK(i][jl:=0; 

END; 

END; 

FOR i:=l TO 8 DO MRLStat[i]:=0;END; 

ZK[ 1][ 1]:=7; ZK[ 1]I 2]:=1; ZK( 1][ 3):=17j ZK( 1][ 4]:=33; 

ZK( 1][ 5):=49; ZK[ 1][ 6]:=57; ZK[ 1][ 7]:=65; ZK( 1][ 8]:=73; 
ZK( 2][ 1]:=4; ZK[ 2][ 21:4; ZK[ 2][ 3]:=18; ZK( 2][ 4]:=34; 

ZK[ 2][ 51:=50; ZK[ 2)[ 6J:=0; ZK[ 21[ 7J:=0; ZK( 21[ 8]:=0; 

ZK( 31 [ 11 :=4; ZK[ 3)[ 2]:=1; ZK( 3|[ 3]:=19; ZK( 3J[ 4]:=35; 

ZK[ 3][ 5] :41; ZK[ 31( 6J:=Ö; ZK[ 3J[ 7]:=0; ZK( 3][ 81:=0; 

ZK( 4][ 1):=7; ZK[ 41[ 2):=1; ZK[ 41[ 31:=20; ZK( 4][ 4]:=36; 

ZK( 4][ 51:=52; ZK[ 4][ 6]:48; ZK[ 41[ 71:=€6; ZK[ 41[ 8J:=74; 

ZK[ 51[ 1]:=4; ZK[ 5J[ 21:=2; ZK[ 51( 3]:=17; ZK( 51[ 4]:=37; 

ZK[ 51( 5]:=67; ZK[ 5]( 6]:=0; ZK[ 51[ 7]:=0; ZK( 51[ 8]:=0; 

ZK[ 611 1):=4; ZK[ 61( 21 :=2; ZK( 61( 31:=18; ZK( 61[ 4]:=38; 

ZKl 61 [ 51 :=57; ZK'[ 61 [ 6J:=0; ZK[ 61 [ 7) :=0; ZK( 61 [ 81 :=0; 

ZK[ 71[ 1]:=4; ZR[ 71( 2]:=2; ZR( 71[ 3J:=19; ZR( 71[ 4]:=39; 

ZK[ 7}[ 51:=58; ZR[ 7][ 61:=0; ZR[ 71[ 7]:=0; ZR[ 7][ 81:=0; 

ZK[ 81! 1J:=4; ZR{ 81( 21:=2; ZR( 81[ 31:=20; ZR( 8J[ 4]:=40; 

ZR[ 81! 5J:=68; ZR[ 81( 6]:=0; ZR[ 81[ 7J:=0; ZR| 81! 8]:=0; 

ZK[ 9)[ 1):=4; ZR[ 91! 2]:=3; ZRf 91! 3]:=17; ZK( 91 [ 4]:=41; 

ZR[ 9)[ 51:=69; ZR[ 91( 61:=0; ZR{ 91! 7J:=0; ZK! 91[ 8J:=0; 
ZR[10J( 1]:=4; ZR[10]( 21:=3; ZR(101[ 3]:=18; ZK[10J[ 41:=42; 
ZR(10]( 51:=58; ZK[10][ €]s-0; ZK110][ 7):=0; ZRI10][ 8J:=0; 
ZRUUI 1]:=4; ZK[11][ 2J:=3; ZK[11][ 31:=19; ZRlllJ! 4J:=43; 
ZK[11][ 5]:=57; ZKI11]{ 6]:=0; ZK(11H 7]:=0; ZK(111( 81:=0; 

ZR[12J! 11 Mi ZR1121I 2J:=3; ZR{1211 3J:=20; ZR[12J [ 41 :=44; 
ZK[12][ 51:=70; ZK[12J[ 6] :=0; ZR112J[ 7]:=0; ZK[121( 81:=0; 

ZK[13]! 1J:=7; ZKJ131[ 2}:=4; ZK{13J[ 31:=17; ZR[131[ 4]:=45; 
ZR[13][ 5]:=53; ZK(13][ 6]:=58; ZK[131[ 7):=71 y ZK[131[ 8]:=75; 
ZK[14][ lj:=4; ZK(14][ 21:=4; ZKI14J[ 3J:=18; ZK[14J[ 41:=46; 

ZK[141[ 51:=54; ZR!14][ 61:=0; ZR[141[ 7):=0; ZR[14J[ 81:=0; 
ZRI151! 1J:=4; ZK[15]! 2J:=4; ZR1151( 3J:=19; ZR[151( 41:=47; 
ZK[15][ 51:=55; ZK[15J[ 6J:=0; ZK[15][ 7):=0; ZR[15][ 81:=0; 
ZK(161f 11:=7; ZK116J! 2J:=4; ZK[161[ 31:=20; ZK[161[ 4J:=48; 
ZK116H 51 :=56; ZK[16][ 6):=57; ZR[161 [ 71 :=72; ZR[161( 81 :=76? 
ZK[17][ lj:=4; ZR[17][ 21:=5; ZKJ171[ 3):=21; ZR[171( 41:=33; 
ZKI17H 51:=59; ZK[171[ 6J:=0; ZR[17][ 7J:=0; ZK[17][ 81:=0; 

ZK(18][ 1]:=4; ZR(18][ 2]:=5; ZR(18][ 3]:=22; ZK[18][ 4]:=34; 

ZK[18][ 51:=65; ZK[18H 6J:=0; ZR[18][ 7]:=0; ZR[181! 8]:=0; 
ZKI19][ 1]:=4; ZK[19][ 2]:=5; ZK[19][ 3]:=23; ZK[19J[ 4]:=35; 
ZK[19][ 51:=66; ZK[191[ 6]:=0; ZK[19][ 7):=0; ZR[19][ 8]:=0; 
ZK[20][ 1]:=4; ZR[20][ 2):=5; ZK[20][ 3]:=24; ZR[201[ 4] :=36; 
ZR[20][ 51:=60; ZR[20][ 6]:=0; ZR[20][ 7]:=0; ZR[20][ 8]:=0; 
ZK[21][ 1] :=4; ZR[21][ 2]:=6; ZR[211[ 3]:=21; ZR[2U[ 4]:=37; 
ZK[21][ 5]:=49; ZK[21][ 6]:=0; ZR[21)[ 7]:=0; ZK[21][ 8]:=0; 
ZK[22][ 11:=7; ZK[22][ 2]:=6; ZR[22J! 3J:=22; ZR[22J[ 4]:=38; 
ZR[22][ 5] :=50; ZR[221[ 6]:=59; ZR[221[ 7]:=67; ZK[221[ 81:=73; 
ZR[23][ 11:=7; ZR[23][ 2]:=6; ZR[23)[ 3]:=23; ZK[23J[ 4]:=39; 

ZK 123][ 5]:=51; ZK[23J[ 6]:=60; ZK[23][ 7]:=68; ZK(23][ 8]:=74; 
ZK[24][ 1]:=4; ZK[241[ 2]:=6; ZK[24][ 3]:=24; ZK[24][ 4]:=40; 

ZK[24][ 5]:=52; ZK[24][ 6]:=0; ZK[24][ 7J:=0; ZK[24][ 8]:=0; 
ZK[25]( 1]:=4; ZK[251[ 2]:=7; ZK[25][ 3]:=21; ZK[2511 4]:=41; 
ZK[25][ 5]:=53; ZK[25][ 6]:=0; ZK[25][ 7]:=0; ZK[25]l 8]:=0; 
ZKI26][ 1]:=7; ZK[26][ 2]:=7; ZK[26][ 3]:=22; ZK[26]l 4]:=42; 
ZK[26][ 51:=54; ZK[26H 6]:=60; ZK[26]! 7]:=69; ZK{26][ 8]:=75; 
ZK[27][ 1]:=7; ZK[27][ 2]:=7; ZK[27][ 3]:=23; ZK[27][ 4] :=43; 


ZK[27][ 5]:=55; ZK(27][ 6]:=59; ZK!27][ 7]:=70; ZK[27][ 8]:=76; 
ZK[28][ 1]:=4; ZK[28]( 2]:=7; ZK[28][ 3]:=24; ZK[28][ 4]:=44; 
ZK[28]I 5]:=56? ZK{28][ 6]:=0; ZK[28][ 7]:=Ö; ZK[28][, 8]:=0; 
ZK[29]( 1]:=4; ZK[29][ 2]:=8; ZK[29][ 3]:=21; ZK(29]( 4]:=45; 
ZK[29]l 5]:=60; ZK[29][ 6]:=0; ZK[29][ 7]:=0; ZK[29][ 8]:=0; 
ZK[30]t U:=4; ZK[30][ 2]:=8; ZK[30]f 3]:=22; ZK[30][ 4]:=46; 

ZK1301[ 5]:=71; ZK(30][ 6]:=0; ZK[30][ 7]:=0; ZK[30][ 8]:=0; 

ZK[31]! 1]:=4; ZK[31][ 2]:=8; ZKI31]( 3]:=23; ZK[31]( 4]:=47; 

ZK[31][ 5]:=72; ZK[31][ 6]:=0; ZK[31]( 7]:=0; ZK[31][ 8]:=0; 
ZK[32][ 1]:=4; ZK[32][ 2]:=8; ZK[32][ 3]:=24; ZK[32]( 4]:=48; 

ZK[32][ 5]:=59? ZK[32]( 6]:=0; ZK[321[ 7]:=0; ZK[32][ 8]:=0; 
ZK[33][ 1]:=4; ZK[33][ 2]:=9; ZK[33][ 3]:=25; ZK[33][ 41:=33; 
ZK[33][ 5]:=61; ZK[33][ 6]:=0; ZK[33][ 7] : =0; ZK[33][ 8]:=0; 
ZK[34][ 1]:=4; ZK[34][ 2]:=9; ZK[34]( 3]:=26; ZK(34][ 41:=34; 
ZK[34][ 5]:=66; ZK[34][ 6]:=0; ZK[34][ 7]:=0; ZK[34][ 8]:=0; 
ZK[35][ 1]:=4; ZK[35][ 2]:=9; ZK[351[ 3]:=27; ZK[35][ 41:=35; 
ZK[35][ 5]:=65; ZK[35][ 6]:=0; ZK[35][ 7]:=0; ZK[35][ 8]:=0; 
ZK[36][ 11:=4; ZK[36][ 2]:=9; ZK[36][ 3]:=28; ZK[36]( 4]:=36; 
ZK(36][ 5]:=62; ZK[36][ 6]:=0; ZK[36][ 7]:=0; ZK[36][ 8]:=0; 
ZK[37][ 1]:=4; ZK[37][ 2]:=10; ZK[37][ 3]:=25; ZK[371[ 4]:=37; 
ZK[37][ 5]:=53; ZK[37][ 6]:=0; ZK[37][ 7]:=0; ZK[37][ 8]:=0; 

ZK[38][ 1]:=7; ZK[38][ 2]:=10; ZK[38][ 3]:=26; ZK[38][ 41:=38; 

ZK[38][ 5]:=54; ZK[38][ 6]:=61; ZK[38][ 7]:=68; ZK[38][ 81:=76; 
ZK[39][ 1]:=7; ZK[393[ 2]:=10; ZK[39][ 3]:=27; ZK[39][ 41:=39; 
ZK[39][ 5]:=55; ZK[39][ 6]:=62; ZK[39]( 7]:=67; ZK[39][ 8):=75; 
ZK[40][ 1]:=4; ZK[40][ 2]:=10; ZK[40][ 3]:=28; ZK[40][ 4J:=40; 
ZK[40][ 5]:=56; ZK[40][ 6]:=0; ZK[40][ 7]:=0; ZK[40][ 8]:=0; 
ZK[41][ 1]:=4; ZK[41][ 2]:=11; ZK[41)[ 3]:=25; ZK[41][ 4]:=41; 

ZK(41]( 5]:=49; ZK[41][ 6]:=0; ZK[41][ 7]:=0; ZK[41][ 8]:=0; 

ZK[42][ 1]:=7; ZK[42][ 2]:=11; ZK[42][ 3]:=26; ZK[42][ 4]:=42; 

ZK[42][ 5]:=50; ZK[42][ 6]:=62; ZK[42][ 7]:=70; ZK[42][ 8]:=74; 
ZK[43][ 1]:=7; ZK[43][ 2]:=U; ZK[43][ 3]:=27; ZK[43][ 41:=43; 

ZK[43][ 5]:=51; ZK[43][ 6]:=61; ZK[43][ 7]:=69; ZK[43][ 81:=73; 
ZK[44][ 1]:=4; ZK[441( 2]:=11; ZK[44][ 3]:=28; ZK[44][ 4]:=44; 
ZK(44][ 5]:=52; ZK[44][ 6]:=0; ZK[44][ 7]:=0; ZK[44][ 8]:=0; 
ZK[45][ 1]:=4; ZK[45][ 2]:=12; ZK[45][ 3]:=25; ZK[45][ 4]:=45; 

ZK[451[ 51:=62; ZK[45][ 6]:=0; ZK[45][ 7]:=0; ZK[45][ 8]:=0; 
ZK[46][ 1]:=4; ZK[46][ 2]:=12; ZK[46][ 3]:=26; ZK[46][ 4]:=46; 
ZK[46][ 5]:=72; ZK[46][ 6]:=0; ZK[46][ 7]:=0; ZK[46][ 81:=0; 
ZK[47][ 1]:=4; ZK[47][ 2]:=12; ZK[47][ 3]:=27; ZK[47][ 4]:=47; 

ZK[47][ 5]:=71; ZK[47][ 6]:=0; ZK[47][ 7]:=0; ZK[47][ 8]:=0; 
ZK[48][ 1] :=4; ZK[48][ 2]:=12; ZK[48][ 3]:=28; ZK(48][ 4]:=48; 
ZK[48][ 5]:=61; ZK(48][ 6]:=0; ZK[48][ 7]:=0; ZK[48][ 8]:=0; 
ZK[49][ 1]:=7; ZK[49][ 2] :=13; ZK[49][ 3] :=29; ZK[49][ 41:=33; 

ZK[49][ 5]:=53; ZK[49][ 61:=63; ZK[491[ 71:=66; ZK[49][ 8]:=76; 
ZK[50][ 1]:=4; ZK[50][ 2]:=13; ZK[50][ 3]:=30; ZK[50][ 4]:=34; 

ZK[50][ 5]:=54; ZK[50][ 6]:=0; ZK[50][ 7]:=0; ZK[50][ 8]:=0; 
ZK(51][ 1]:=4; ZK[51][ 2]:=13; ZK[51][ 3]:=31; ZK[51][ 4]:=35; 
ZK[51][ 5]:=55; ZK(51][ 6]:=0; ZK[51][ 7]:=0; ZK[51][ 8]:=0; 
ZK[52]( 1]:=7; ZK[52][ 2]:=13; ZK[52][ 3]:=32; ZK[52][ 4]:=36; 

ZK[52][ 5]:=56; ZK[52][ 6]:=64; ZK[52][ 7]:=65; ZK[52][ 81:=75; 
ZK[53][ 1]:=4; ZK[53][ 2]:=14; ZK[53][ 3]:=29? ZK[533[ 4]:=37; 
ZK{53][ 5]:=68; ZK[53][ 6]:=0; ZK[53][ 7]:=0; ZK[53][ 8]:=0; 
ZK[54][ 1] :=4; ZK[54][ 2]:=14; ZK[54][ 3]:=30; ZK[54][ 4]:=38; 

ZK[54][ 51:=63; ZK[54][ 6]:=0; ZK[54)[ 7]:=0; ZK[54][ 8]:=0; 
ZKJ55][ 1]:=4; ZK[55][ 2]:=14; ZK[55][ 3]:=31; ZK[55][ 4J:=39; 
ZKJ55][ 51:=64; ZK[55][ 6]:=0; ZK[55][ 7]:=0; ZK[55][ 81:=0; 
ZK[56][ 11:=4; ZK[56][ 2]:=14; ZK[56][ 3]:=32; ZK[56][ 41:=40; 
ZK[56][ 51:=67; ZK{56][ 6]:=0; ZK[56][ 7]:=0; ZK[56][ 8]:=0; 
ZK[57][ 1]:=4; ZK[57][ 2]:=15; ZK[57][ 3]:=29; ZK[57][ 41 :=41; 
ZK[57][ 5]:=70; ZK{57][ 6]:=0; ZK[57][ 7]:=0; ZK[57][ 8]:=0; 
ZK{58][ 1J:=4; ZK[58][ 2]:=15;-ZK[58][ 3]:=30; ZK[58][ 4]:=42; 
ZK[58][ 5]:=64; ZK[58][ 6J:=0; ZK[58][ 7]:=0; ZK[58][ 8]:=0; 
ZK[59][ 11:=4; ZK(59][ 2]:=15; ZK[59][ 3]:=31; ZK[59][ 4]:=43; 
ZK[59][ 5]:=63; ZK[59][ 6]:=0; ZK[59][ 7]:=0; ZK[59][ 8]:=0; 
ZK[60][ 11 :=4; ZK[60][ 2]:=15; ZK[60][ 31:=32; ZK[60][ 4]:=44; 
ZK[60][ 5]:=69; ZK{60][ 61:=0; ZK[60][ 7]:=0; ZK[60][ 8]:=0; 
ZK[61][ 1]:=7; ZK(61][ 2]:=16; ZK[61][ 3]:=29; ZK[61][ 4]:=45; 
ZK[61][ 51:=49; ZK[61][ 6J:=64; ZK[61][ 7]:=72; ZK[61][ 8]:=74; 
ZK[62][ 11:=4; ZK[62][ 2]:=16; ZK[62][ 3]:=30; ZK[62][ 4]:=46; 

ZK[62][ 5]:=50; ZK[62}[ 6]:=0; ZK[62][ 7]:=0; ZK[62][ 8]:=0; 
ZK[63][ 1]:=4; ZK[63][ 2):=16; ZK[63][ 3]:=31; ZK[63][ 41:=47; 
ZK[63][ 51:=51; ZK[63][ 6]:=0; ZK[63][ 7]:=0; ZK[63][ 8]:=0; 

ZK[64][ 11:=7; ZK[64][ 2]:=16; ZK[64][ 3]:=32; ZK[64][ 4]:=48; 
ZK[64][ 5]:=52; ZK[64][ 6]:=63; ZK[64][ 7]:=71; ZK[64][ 8]:=73; 
FOR i:=l TO 76 DO FOR j:=5 TO 6 DO MHL[i][jl:=0;END;END; 

(* senkrechte »Ihlen *) 

MHL[ 1][ 11:4; MHL[ 1J[ 2):=2; MHL[ 1][ 3]:=3; HHL[ 1] [ 4]:=4; 

MHL[ 2][ 1):=5; MHL[ 2][ 2J:=6; MHL[ 2][ 3J:=7; MHL[ 2][ 4}:=8; 

MHL{ 3][ 1]:=9; MHL[ 3][ 2]:=10; MHL[ 3][ 3]:=U; MHL[ 3][ 4]:=12 
MHL[ 4][ 1]:=13; MHL[ 4][ 21:44; HHL[ 4][ 3]:=15? MHL[ 4][ 4]:=16 

MHL[ 5] [ 11:47; MHL[ 5][ 2]:=18; MHL[ 5] [ 31:49; MHL[ 5][ 4]:=20 


MHL[ 6][ 11:41; MHL[ 6][ 2]:=22; MHL[ 6][ 3]:=23; MHL[ 6][ 4]:=24 

MHL[ 7] [ 1]:45? MHL[ 7] [ 2] :=26; MHL[ 7] [ 3]:=27; MHL[ 7][ 4]:=28 

MHL[ 8][ 1):=29; MHL[ 8]( 21:=30; MHL[ 81 [ 3]:=31; MHL[ 8][ 4]:=32 

MHL[ 9][ 1):=33; HHL[ 9][ 2]:=34; MHL[ 9][ 3]:=35; MHL[ 9][ 4]:=36 

MHL[10][ 1]:=37; MHL[10][ 2]:=3ß; MHL[10][ 3]:=39; MHL[10][ 4]:=40 
MHL[11][ U:=41; MHL[11][ 2]:=42; HHL[11)[ 3]:=43; MHL[11][ 4]:=44 
MHL[12][ 1]:=45; MHL[12][ 2]:=46; MHL[12][ 3]:=47; MHL[12][ 4]:48 
MHL[13][ 1]:49; HHL[13][ 2]:=50; HHL[13][ 3]:=51; MHL[13][ 4]:=52 
MHL[14][ 11:43; MHL[14][ 2]:=54; MHL[14][ 3]:=55; MHL[14][ 4]:=56 
MHL[15][ 1]:=57; MHL[15][ 2]:48; MHL[151[ 3]:=59; MHL[15][ 4]:=60 
MHL[16][ 1]:41; MHL[16][ 2]:=62; MHL[16][ 3]:=63; MHL[16][ 4]:=64 
(* waagerechte Mühlen *) 

MHL[17)[ 1]:=1; MHL(17][ 2]:=5; MHL[17][ 31:4; MHL[17][ 4]:=13; 
MHL[18][ 1]:=2; MHL[18][ 2]:=6; MHL[18][ 31:40; MHL[18][ 4]:=14 

MHL[19][ 1]:=3; MHL[19][ 2]:=7; MHL[19][ 3]:41; MHL[19)[ 41:45 

MHL[20] ( 1] :=4; MHL[20][ 2]:=8; MHL[201 [ 3]:42; MHL[20] [ 41:46 

MHL[21][ 11:47; MHL[21][ 2]:41; MHL[21][ 3] :=25; MHL[21][ 4]:=29 
MHL[22][ 1]:=18; MHL[22][ 2]:=22; MHL[22][ 3]:=26; MHL[22][ 4]:=30 
MHL[23][ 1]:=19; MHL[23][ 2]:=23; MHL[23][ 3]:=27; MHL[23][ 4]:=31 
MHL[24][ 11:40; MHL[24][ 2]:=24; MHL[24][ 3):=28; MHL[241[ 4]:=32 
MHL[25] [ 1]:=33; MHL[25][ 2]:=37; MHL[25][ 3]:=41; MHL[25][ 41:45 
MHL[26][ 1]:=34; MHL[26][ 2]:=38; MHL[26][ 3]:=42; MHL[26][ 4]:46 
MHL[27][ 11:45; MHL[271[ 2] :=39; MHL[27][ 3]:=43; MHL[27][ 4]:=47 
MHL[28] [ 11:46; MHL[28] [ 2}:=40; MHL[28][ 3]:=44; MHL[28][ 4]:48 
MHL[29][ 1]:49; MHL[29][ 2]:=53; MHL[29][ 3]:=57; MHL[29][ 4]:=61 
MHL[30] [ 11:40; MHL[30][ 2] :=54; MHL[30][ 3] :=58; MHL[30][ 4]:=62 
MHL[31][ 1]:41; MHL[31][ 2]:=55; MHL[31][ 3]:=59; MHL[31][ 4]:=63 
MHL(32][ 1]:42; MHL[32][ 2]:=56; MHL[32][ 3]:=60; MHL[32]( 4]:=64 
MHL[33][ 11:4; MHL[33][ 2]:=17; MHL[33][ 3]:=33; MHL[331[ 4]:=49 

MHLJ34]( 1]:=2; MHL[34][ 21:48; MHL[34][ 3]:=34; MHL[34][ 4J:=50 

MHL[35][ 1]:=3; MHL[35][ 2]:=19; MHL[35][ 3]:=35; MHL[35][ 41:41 

MHL[36][ 1]:=4; MHL[36][ 2]:=20; MHL[36][ 3]:=36; MHL[36][ 41:42 

MHL[37]( 1]:4; MHL[37][ 2]:=21; MHL[37][ 3]:=37; MHL[37J[ 41:43 

MHL138] [ 1] :=6; MHL[38][ 2] :*=22; KHL[38][ 3] :=38; MHL[38][ 4]:=54 

MHL[39] ( 11:4; MHL[39][ 2]:=23; MHL[39][ 3]:=39; MHL[39][ 41:45 

MHL[40][ 1]:=8; MHL[40][ 2]:=24; MHL[40][ 3]:=40; MHL[40][ 4):=56 

MHL[41] [ 1] :=9; MHL[41][ 2]:=25; MHL[41][ 3]:=41; MHL[41][ 4]:47 

MHL[42] [ 1]:=10; MHL[42] [ 2]:=26; MHL[42][ 31:=42; MHL[421[ 4]:48 

MHL[43][ 11:41; MHL[43] [ 2]:=27; MHL[43][ 3]:=43; MHL[43][ 4]:49 

MHL[44][ 11:42; MHL[44][ 2]:=28; MHL[44][ 31:=44; MHL[44)[ 4]:=60 
MHL[45][ 1]:=13; MHL[45][ 2]:=29; MHL[45][ 3]:=45; MHL[45][ 4]:=61 
MHL[46][ 11:44; MHL[46][ 2]:=30; MHL[46][ 3]:=46; MHL[46][ 4]:=62 
MHL[47][ 1]:45; MHL[47][ 2]:=31; MHL[47][ 3]:=47; MHL[47][ 4]:=63 
MHL[48] [ 11:46; MHL[48][ 2]:=32; MHL[481[ 3]:=48; MHL[48][ 4]:=64 
MHL[49][ 11:4; MHL[49][ 2]:=21; MHL[49]{ 3]:=41; MHL[49][ 4]:=61 
MHL[50][ 1]:=2; MHL[50][ 2]:=22; MHL[50][ 3] :=42; MHL(50][ 4]:=62 
MHL[51][ 11:=3; MHL[51][ 2]:=23; MHL[51][ 3]:=43; MHL[51][ 4]:=63 
MHL[521[ 1] :=4; MHL[52][ 2]:=24; MHL[52][ 3]:=44; MHL[52][ 4]:=64 
MHL[53][ 11:43; MHL[53][ 2]:=25; MHL[531[ 3]:=37; MHL[53][ 4]:=49 
MHL[54] [ 11:44; MHL[54][ 2]:=26; MHL[54][ 3]:=38; MHL[54][ 4]:40 
MHL[55] [ 1]:=15; MHL[55][ 21 :=27; MHL[55][ 3]:=39; MHL[55][ 41:41 
MHL[56][ 11:46; MHL[56][ 2]:=28; MHL[56][ 3]:=40; MHL[56][ 4]:=52 
(* diagonale Mühlen *) 

MHL[57][ 11:4; MHL[57][ 2] :=6? MHL[57][ 31:41; MHL[57J[ 41:46 

MHL[58][ 1]:=4; MHL[58][ 2]:=7; MHL(58][ 3]:=10; MHL[581[ 41:43 

MHL[59][ 11:47; MHL[591[ 2]:=22; MHL[59][ 3]:=27; MHL[59][ 4]:=32 
MHL[60][ 1):=20; MHL[60][ 2]:=23; MHL[60][ 3]:=26; MHL[60][ 4]:=29 
MHL[61][ 1]:=33; MHL[61][ 2]:=38; MHL[61][ 3]:=43; MHL[61][ 41:=48 
MHL[62][ 11:=36; MHL[62][ 2]:=39; MHL[62][ 3]:=42; MHL[62][ 4]:=45 
MHL[63][ 1]:=49; MHL[63][ 21:44; MHL[631[ 3]:=59; MHL[63][ 4]:=64 
MHL[64][ 1]:=52; MHL[64][ 2]:=55; MHL[64][ 3]:=58; MHL[64][ 41:=61 
MHL[651( 11:4; MHL[65][ 21:48; MHL[65][ 3]:=35; MHL[651[ 4]:42 
MHL166][ 1J:=4; MHL[66][ 2]:=19; MHL[66][ 3]:=34; MHL[66][ 4]:=49 
MHL[671[ 1]:=5; MHL[67][ 2]:=22; MHL[67]( 3]:=39; MHL[67][ 41:46 
MHL[68]( 1]:=8; MHL[68][ 2]:=23; MHL[68][ 31:=38; MHL[68][ 41:43 
MHLJ691[ 1]:=9; MHL[69][ 2]:=26; MHL[69][ 3]:=43; MHL[69][ 4]:=60 
MHLI70] [ 1]:42; MHL[70][ 2]:=27; MHL[70][ 3] :=42; MHL[70][ 4]:=57 
MHL[71][ 11:43; MHL[71]( 2):=30; MHL[71][ 3]:=47; MHL[71][ 4]:=64 
MHL[72][ 1]:46; MHL[72][ 2]:=31? MHL[72][ 3]:=46; MHL[72][ 4]:=61 
(* raumdiagonale Mühlen *) 

MHL(73][ 11:4; MHL[73][ 21:=22; MHL[731[ 3J:=43; MHL[731[ 4]:=64 
MHL[74][ 1]:=4; MHL[74][ 2]:=23; MHL[74][ 3]:=42; MHL[74][ 4J:=61 
MHL[75][ 11:43; MHL[75][ 2]:=26; MHL[75][ 3]:=39; MHL[75][ 44:42 
MHL[76][ 1]:=16; MHL[761[ 2]:=27; MHL[76][ 3]:=38; KHL[76][ 4J:=49 
FOR i:=l TO 64 DO Board[i]:=pin;END; 

SetStatusInfo(l); 

SetDepth(1); 

END InitStrat; 

END sogostrat. © 1993 M&T 


»Listing 4: Das Implementationsmodul des 
»Strategiekerns« unseres Spiels 
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GRUNDLAGEN 


Libraries für BASIC 

Selbstgestrickt 


Wie programmiert man eigentlich 
eine Library? Raphael Koch aus 
Vechelde beschreibt, wie man 's 
macht und wie Sie Ihre eigene 
Funktionsbibliothek dann von 
BASIC aus nutzen. 

von Raphael Koch 

D as Betriebssystem des Amiga besteht 
zu einem sehr großen Teil aus den 
Libraries. Das ist auch sehr praktisch, 
denn eine schon bestehende Library kann 
man recht einfach um Befehle und Funktio¬ 
nen erweitern. Zur Erinnerung: Befehle und 
Funktionen unterscheiden sich dadurch, daß 
eine Funktion einen Wert als Retumcode im 
Register dO liefert und ein Befehl nicht. 

Aber das Programmieren einer - eigenen - 
neuen Library, die von Diskette nachgeladen 
wird, ist schon eine Wissenschaft für sich. 
Um Ihnen das Ganze einfacher zu machen, 
zeigen wir Ihnen hier, wie so eine Library 
erstellt wird. 

Wenn das Betriebssystem eine Library von 
der Diskette nachlädt, werden eine ganze 
Menge Routinen intern vom Betriebssystem 
aufgerufen, um die Library im Speicher zu 
initialisieren. Wer mehr über die Theorie der 
Initialisierung erfahren möchte, sei auf den 
siebten Teil des Insiderkurses im AMIGA 
Magazin, Ausgabe 11, im Jahr 1989 verwie¬ 
sen. Dazu werden eine ganze Menge Daten 
benötigt, die wir in unserem Programm fest¬ 
legen müssen (siehe Listings Seite 46). 

Da das Betriebssystem Libraries wie Resi- 
dent-Module behandelt, schreiben wir als 
erstes eine Resident-Struktur in unser Pro¬ 
gramm. Diese sieht wie der Tabelle unten 
gezeigt aus: 


Offset 

(Dez.) 

Größe 

Bedeutung 

0 

word 

Kennung für Resident-Struktur 
dez.: 19196 hex:4AFC 

2 

aptr 

Zeiger auf Anfang der Struktur 

6 

aptr 

Zeiger auf Programmende 

10 

byte 

Flags: wir tragen hier 128 ein 

11 

byte 

für Eintrag Library-Version 

12 

byte 

Type: für Library 9 eingetragen 

13 

byte 

Die Priorität: normal ist 0 

14 

aptr 

Zeiger auf Namen der Library 

18 

aptr 

Zeiger auf Identifikationsstring 

22 

aptr 

-> Anfang der Liblnit-Struktur 


In einer Resident-Struktur muß auf jeden 
Fall als allererstes ein Identifikationscode ste¬ 
hen. Hier lautet er 19196. In unser Library 
steht also als erstes nach den Konstantenzu¬ 


weisungen und den eventuellen Include- 
Befehlen die Zeile 
dc.w 19196 
oder 

dc.w $4AFC 

Oder, wer es lieber mag, kann auch 
illegal 

eintragen. Und damit das Betriebssystem 
ganz sicher sein kann, daß es sich um ein 
Resident-Modul handelt, muß als nächstes 
ein Zeiger auf den Beginn des Resident- 
Moduls stehen. Also steht im Programm: 
ResidentStruct dc.w 19196 

dc.l ResidentStruct 

Wer seine Library ganz narrensicher 
gestalten will, kann vor der Resident-Struktur 
auch noch 
moveq #20,dO 
rts 

ins Programm schreiben, um bei einem even¬ 
tuellem Start vom CLI durch einen unerfah¬ 
renen Anwender einen Absturz zu verhin¬ 
dern. Aber jetzt weiter in der Resident-Struk¬ 
tur: Nach den Sicherheitszeilen muß dem 
System noch mitgeteilt werden, bis wohin 
unser Resident-Modul, also die Library, im 
Speicher reicht. Dazu schreiben wir hinter 
den letzten Befehl und hinter die letzte 
Assemblerdirektive eine Sprungmarke. Diese 
Marke tragen wir als nächstes in unsere 
Struktur ein. Die weiteren Einträge dürften 
sich selbst erklären. 

Die folgende Tabelle zeigt die »InitLib«- 
Struktur: 


Offset (Dez.) 

Bedeutung 

0 

Die Größe der Basis 

4 

Zeiger auf die Sprungtabelle 

8 

Zeiger auf eine Datentabelle 

12 

Zeiger auf die InitLib Routine 


Bei der Datentabelle handelt es sich um 
Daten, mit denen die Basis unserer Library 
initialisiert wird. (Da wir auf Include-Files, in 
Hinsicht auf diejenigen, die keine benutzen 
können, verzichten möchten, werden die 
benötigten Makros am Anfang unserer Bei¬ 
spiel-Library beschrieben. Die Include-Files, 
die wir dennoch genutzt haben, können Sie 
mit dem Programm »Makelnclude« selbst 
aus den lib.fd's für BASIC generieren.) Die 
Tabelle wird durch das Langwort Null (0) 
abgeschlossen.Im allgemeinen wird folgen¬ 
des eingetragen: 

DataTable INITBYTE 8,9 ; Type: Library 
INITLONG 10,xxxName ; LibName 
INITBYTE 14,6 ; Flags: SUMÜSED & CHANGED 
INITWORD 20,Version ; Versionsnummer 
INITWORD 22,Revision ; Revisionsnummer 


INITLONG 24,xxxLibID ; LiblDString 
dc.l 0 ; End 

Die Revisionsnummer ist eine Überarbei¬ 
tungsnummer, die dann erhöht wird, wenn an 
der Library kleine Änderungen vorgenom¬ 
men wurden, die keine Erhöhung der Ver¬ 
sionsnummer rechtfertigen. Andere Daten 
werden nicht initialisiert, weil dies das 
System beim Erstellen der Library macht. 
Beim dritten Eintrag handelt es sich um einen 
Zeiger auf eine »InitLib«-Routine. Sie wird 
beim ersten Öffnen der Library aufgerufen. 
Das Betriebssystem übergibt uns im Register 
dO die Basisadresse unserer Library und in aO 
die Adresse der »Segmentliste«. Beides soll¬ 
ten wir auf jeden Fall merken. Normaler¬ 
weise wird die Adresse der Segmentliste in 
der Basis der Library gespeichert und die 
Basisadresse merkten wir uns in der Varia¬ 
blen _xxxBase (xxx steht für den Namen 
Ihrer Library). Der Pflichtteil von InitLib ist 
also folgender: 

InitLib movem.l al/a5,-(sp) 
move.l d0,a5 
lea.l _xxxBase(pc),al 
move.l dO,(al) 
move.l a0,34(a5) 
move.l a5,d0 

Endlnit movem.l (sp)+,al/a5 
rts 

Wenn für die Befehle und Funktionen der 
eigenen Library noch andere Libraries, wie in 
unserem Beispiel die »graphics.library«, 
benötigt werden, können diese hier geöffnet 
werden. Es empfiehlt sich, die Basisadressen 
der Libraries in der eigenen Library-Basis zu 
speichern. 

Die Sprungtabelle ist entweder eine Lang¬ 
wort- oder eine Worttabelle. Wählen Sie die 
Langworttabelle, stehen in ihr Zeiger auf die 
Befehle und Funktionen der Library. Möch¬ 
ten Sie aber eine Worttabelle benutzen, steht 
als erstes: 
dc.w -1 

Die folgenden Einträge bestehen dann aus 
Adreßdistanzen zwischen Beginn der 
Sprungtabelle und den jeweiligen Routinen. 
Beide Tabellen werden durch 
dc.l -1 

beendet. Die Wort-Tabelle für unsere Bei¬ 
spiel-Library sieht dann so aus: 

FunctionTable 
dc.w -1 

dc.w Open - FunctionTable 
dc.w Close - FunctionTable 
dc.w ExpugneLib - FunctionTable 
dc.w ExtFuncLib - FunctionTable 
dc.w DrawTriangle - FunctionTable 
dc.w GetAPen - FunctionTable 
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dc.w GetBPen - FunctionTable 
dc.l -1 

Und die Langworttabelle so: 

FunctionTable de. 1 Open 

dc.l Close 

dc.l ExpugneLib 

dc.l ExtFuncLib 

dc.l DrawTriangle 

dc.l GetAPen 

dc.l GetBPen 

dc.l -1 

Die ersten vier Einträge zeigen auf Routi¬ 
nen die normalerweise nur intern gebraucht 
werden: 

□ Open: Diese Routine wird immer dann 
vom System aufgerufen, wenn ein Task die 
Library mit »OpenLibraryO« öffnen möchte. 
Wenn wir in der Open-Routine landen, 
erhöhen wir den Inhalt von Adresse Basis+32 
(der Inhalt dieser Adresse gibt an, wieviele 
Tasks die Library im Moment benutzen) und 
löschen in den Library-Flags Bit 3. Die 
benötigte Basisadresse liefert uns das System 
in Register a6. Diese müssen wir vor dem 
Rücksprung aus der Routine ins Register dO 
übertragen. Demnach sieht die Open-Routine 
mindestens so aus: 

Open addq.w #l,32(a6) 
bclr.b #3,14(a6) - 

move.l a6,d0 
rts 

□ Close: Die Routine stellt das Gegenteil der 
Open Routine dar, d.h. - wie sollte es auch 
anders sein daß sie immer dann angesprun¬ 
gen wird, wenn ein Task die Library mittels 
»CloseLibraryO« schließt. Hier muß aller¬ 
dings noch überprüft werden, ob hiermit der 
letzte Task die Library geschloßen hat. Ist 
das der Fall, wird die »ExpugneLib()«-Rou- 
tine aufgerufen (s.u.). Also sieht die Close- 
Routine z.B. so aus: 

Close subq.w #l,32(a6) 
btst.b #3,14(a6) 
beq.s EndClose 
bsr.s Expugne 
EndClose rts 

□ ExpugneLib: Die Routine kann entweder 
bei Speicherknappheit von anderen Tasks 
oder von der Close-Routine aufgerufen wer¬ 
den. Bei ExpugneLib und auch bei Close lie¬ 
fert uns das Betriebssystem in a6 die Basis¬ 
adresse unserer Library. Als erstes wird hier 
überprüft, ob kein Task die Library mehr 
benutzt. Ist das nicht der Fall, wird Bit 3 der 
Library-Flags gesetzt und dann erfolgt der 
Rücksprung mit einer 0 als Retumcode in dO. 

Wenn allerdings der letzte Task die Biblio¬ 
thek geschloßen hat, wird eine Routine ange¬ 
sprungen, die in unserem Beispiel »Discard- 
Lib()« heißt. Sie räumt alles auf, d.h., daß 
eventuell bei InitLib geöffnete Libraries wie¬ 
der geschlossen werden und unsere Library 
aus der Systemliste der geöffneten Libraries 
entfernt wird. Das geschieht dadurch, daß wir 
mit der Basisadresse unserer Library im 
Register al »RemoveO« aus der »exec.- 
library« aufrufen. Nun holen wir uns die 
Adresse der Segmentlist aus der Basis zurück 
und merken sie uns z.B. im Register d7 oder 


auf dem Stack. Ist dies geschehen, bringen 
wir die Basisadresse unserer Library ins 
Register aO, schreiben die Größe der Sprung¬ 
tabelle in Register dO und ziehen dO von aO 
ab. Dann addieren wir die Größe der Basis 
auf dO und rufen »FreeMemO« auf (exec.- 
library) auf. Zu guter Letzt bringen wir die 
Adresse der Segmentliste ins Register dO und 
springen zurück. Eine Expugne-Routine 
könnte also so aussehen: 

ExpugneLib movem.l d7/al/a5/a6,-(sp) 
move.l a6,a5 
tst.w 32(a5) 
beq.s DiscardLib 
bset #3,14(a5) 
clr.l dO 

ExpEnd movem.l (sp)+,d7/al/a5/a6 
rts 

DiscardLib move.l _SysBase,a6 
move.l a5,al 
jsr _LV0Remove(a6) 
move.l 34(a5),d7 
clr.l dO 
move.l a5,al 
move.w 16(a5LdO 
sub.l dO,al 
add.w 18(a5),d0 
jsr _LV0FreeMem(a6) 
move.l d7,d0 
bra.s ExpEnd 

□ ExtFuncLib: Diese Routine ist für künftige 
Erweiterungen reserviert und wird noch nicht 
genutzt. Deshalb schreiben wir sicherheits¬ 
halber in das Register dO eine 0 und springen 
zurück. 

Bleibt noch die Größe der Basis zu 
erklären. Sie errechnet sich folgendermaßen: 
34 (für den Systemteil der Struktur) + Zahl 
Zahl steht für die Größe der eigenen Daten 
in Byte. Es gibt nämlich die Möglichkeit, die 
Basis beliebig zu vergrößern, um darin Daten 
wie Basisadressen anderer Libraries unterzu¬ 
bringen. 

Assembler-Routinen 
von BASIC aus 
nutzen 

Der Systemteil der Library-Basis setzt sich 
wie in der Tabelle rechts oben zusammen: 

Damit wäre dann der Rumpf der Library 
fertig. Nun können Sie nach Herzenslust (so 
lange der Speicher reicht) Befehle und Funk¬ 
tionen programmieren. Beginnen Sie jeden 
mit einer Sprungmarke und tragen Sie dann 
dieselbe in der Sprungtabelle direkt hinter die 
internen Routinen ein. 

Das Listing »xxx.library.asm« zeigt, wie 
das Ganze in Assembler aussieht. Das 
zugehörige BASIC-Programm »xxxTest.bas« 
demonstriert den Einsatz von Routinen aus 
der eigenen Bibliothek von BASIC aus. All¬ 
gemein zur Programmierung ist noch zu 
sagen: 

- PC-relative Programmierung ist angesagt !! 
(die Branch-Befehle sind von Natur aus PC¬ 
relativ) 


Offset Größe Bedeutung 
(Dez.) 

0 

struct Hier ist eine Node-Struktur 
eingebunden 

14 

byte Die Libraryflags 

15 

byte Ein Füllbyte 

16 

word Größe der Spriingtabelle 

18 

word Größe der Basis 

20 

ward Versionsnummer 

22 

word Revisionsnummer 

24 

aptr Zeiger auf Identifikationstring 

28 

long Checksumme der Library 

32 

word Anzahl der Tasks, welche 
die Library nutzen 

34 

wählbar für eigene Daten 

Die Libraryflags: 

Wert 

Bedeutung 

1 

Gerade wird die Checksumme berechnet 
(brauchen wir nicht) 

2 

Checksumme muß neu berechnet werden 

4 

Checksumme soll vom Betriebssystem 
überprüft werden 

8 

Library soll entfernt werden: wird aber 
noch benutzt 

Die Nöde-Struktur: 

Offset Größe Bedeutung 

(Dez,) 

0 

aptr (hier) Zeiger vorhergehende 

Library 

4 

aptr (hier) Zeiger nachfolgende 

Library 

8 

byte Da dies eine LibJNode ist. 

wird 9 eingetragen 

9 

byte Priorität: normalerweise 0 

10 

aptr (hier) Zeiger Library - Namen 


Der Systemteil einer Library im Detail 
(siehe auch Listing folgende Seite) 

- Returncodes von Funktionen müssen im 
Register dO geliefert werden. Bei Befehlen 
sollte man auf alle Fälle dO löschen. 

- Bei jeder Library-Routine müssen die 
benutzten Register auf den Stack gerettet 
werden. Wenn das unterbleibt, werden sich 
die Tasks, die Ihre Library gebrauchen, 
höchstwahrscheinlich mit einem Display- 
Alert bedanken. Davon ausgenommen sind 
natürlich die sog. Schmierregister also dO und 
aO. Eigentlich gehöhren dl und al auch dazu, 
worüber man sich allerdings auch streiten 
kann. Außerdem ausgenommen sind die 
Register, in denen wir von den aufrufenden 
Tasks Werte ertfgegennehmen. 

Wenn wir nun die Library nach unseren 
Wünschen fertiggestaltet haben, müssen wir 
eine »xxxjib.fd« schreiben (Für unser Bsp. 
zu finden auf der PD-Diskette zum Heft; 
siehe Seite 114). Diese wird benötigt, um mit 
dem Programm »Makelnclude« das Include- 
File für die Assembler-Programmierer und 
mit dem bekannten ConvertFD das ».bmap«- 
File für die BASIC-Programmierer zu gene¬ 
rieren. Eine »Jib.fd« zu schreiben, ist eigent¬ 
lich nich so schwer, denn es gibt nur sieben 
Kommandos. In jeder Zeile darf nur eines 
stehen:. 

Erstes Kommando (»*«): Durch den Stern 
wird eine Bemerkung eingeleitet. Nach 
einem Stern wird also der Rest der Zeile 
ignoriert. 

Zweites Kommando ("): Wenn die Zeile 
weder mit »*« noch mit »##« beginnt, wird 
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die Zeile so interpretiert: Als erstes steht der 
Name der Funktion oder des Befehls unter 
dem Sie von BASIC aus aufgerufen werden. 
Der Name geht bis dahin, wo die erste Klam¬ 
mer auf (»(«) erscheint. In dieser Klammer 
stehen die Namen der zu übergebenden 
Werte, die aber nur zu Dokumentations¬ 
zwecken gut sind. Die Namen werden durch 
Kommas getrennt angegeben. In der nächsten 
Klammer werden die Register (wieder durch 
Kommas getrennt) angegeben, in die die 
Werte übergeben werden sollen. Wichtig: 
Die Namen der Routinen müssen in der 
lib.fd-Datei in gleicher Reihenfolge angege¬ 
ben werden, wie sie in der Sprungtabelle der 
Library stehen! 

Libraries machen 
selbst BASIC schnell 

Alle folgenden Kommandos werden durch 
»##« am Anfang der Zeile gekennzeichnet. 

Drittes Kommando (»base«): Nach diesem 
Kommando steht ein Leerzeichen und dann 
der Name der Basis unserer Library. 

Viertes Kommando (»bias«): Der Wert 
hinter diesem Kommando gibt an, wieviele 
Routinen in der Sprungtabelle für interne 
Nutzung bestimmt sind. 

Wert = (Anzahl der internen Routinen + 1)*6 

Gewöhnlich sind es vier Routinen, wie 
oben beschrieben. Das heißt: Wert = (4 + 
l)*6 also Wert = 30 

Fünftes Kommando (»end«): Dieses Kom¬ 
mando sagt dem Programm, daß es seine 
Arbeit beenden kann. 

Sechstes Kommando (»public«): Alle 
nachfolgenden Routinen können von mehre¬ 
ren Tasks gleichzeitig genutzt werden. 

Siebtes und letztes Kommando (»private«): 
Alle nachfolgenden Routinen können immer 
nur von einen Task zur Zeit genutzt werden. 
Sie können dann aber selbstverständlich von 
mehreren Tasks hintereinander angesprungen 
werden. Aber dieses Kommando wird nur in 
ganz speziellen Fällen gebraucht. 

Die Jib.fd für unsere Beispiel-Library 
sieht demnach folgendermaßen aus: 

* die lib.fd wird benötigt, um die .bmap 

zu erzeugen 

* Und diese braucht AmigaBASIC zum 

Ansprechen der Routinen. 

##base _xxxBase 
##bias 30 
##public 

DrawTriangle(xl,yl,x2,y2,x3,y3,RastPort) 
(d0,dl,d2,d3,d4,d5,al) 

GetAPen(RastPort)(al) 

GetBPen(RastPort)(al) 

##end 

Wenn Sie Ihre eigene Library erstellen, 
setzen Sie bitte überall, wo wir in diesem 
Kurs »xxx« verwendet haben, den Namen 
Ihrer Library ein. So das war's dann auch 
schon! Wie sagt doch der Mathematiker; »Es 
ist alles ganz einfach, wenn man halt weiß, 
wie'sgehtü« ub 


1: RANDOMIZE TIMER 

2: LIBRARY "dfO:Library/xxx.library" 

3: DECLARE FUNCTION GetAPen&(RastPort) LIBRA 
RY 

4: DECLARE FUNCTION GetBPenSc(RastPort) LIBRA 
RY 

5: REM *** DrawTriangle ist keine Funktion s 
ondern ein Befehl 
6: RastPortSc = WIND0W(8) 

7: COLOR 2,3:PrintColor 
8: DrawTrianglefc 110,50,10,100,210,100,RastP 
ort& 

9: COLOR 1,0:LOCATE 2, 1:PrintColor 
10: DrawTrianglei CINT(RND*610),CINT(RND*186) 
,CINT(RND*610),CINT(RND*186),CINT(RND*610 
),CINT(RND*186),RastPort& 

11: LIBRARY CLOSE 
12: LOCATE 3,1 
13: END 
14: 

15: SUB PrintColor STATIC 

16: SHARED APen%,BPen%,RastPort& 

17: APenl = GetAPen&(RastPorti) 

18: BPen% = GetBPeni(RastPorti) 

19: PRINT "Vordergrundfarbe ist"APen%"und 

Hintergrundfarbe isfBPenl 
20: END SUB 
21: 

22: © 1993 MScT 

»xxxTest.bas«: Das Listing zeigt, wie wir 
unsere Library von BASIC nutzen 


1 

Version equ 1 

2 

Revision equ 1 

3 

include ":include/graphics_lib.i" 

4 

include ":include/exec_lib.i" 

5 

INITBYTE macro 

6 

dc.b $e0 

7 

dc.b 0 

8 

dc.w \1 

9 

dc.b \2 

10 

dc.b 0 

11 

endm 

12 

INITWORD macro 

13 

dc.b $d0 

14 

dc.b 0 

15 

dc.w \1 

16 

dc.w \2 

17 

endm 

18 

INITLONG macro 

19 

dc.b $c0 

20 

dc.b 0 

21 

dc.w \1 

22 

dc.l \2 

23 

endm 

24 

move.l #20,dO 

25 

rts 

26 

ResidentStruct dc.w 19196 ; o. 'illegal 


' o. 'dc.w 54AFC' 

27 

dc.l ResidentStruct 

28 

dc.l End 

29 

dc.b 128 

30 

dc.b 1 

31 

dc.b 9 

32 

dc.b 0 

33 

dc.l xxxName 

34 

dc.l xxxLibID 

35 

dc.l Start 

36 

Start dc.l 42 ; Größe der Basis = 34+L 


änge der Daten 

37 

dc.l FunctionTable 

38 

dc.l DataTable 

39 

dc.l InitLib 

40 

FunctionTable dc.l Open 

41 

dc.l Close 

42 

dc.l ExpugneLib 

43 

dc.l ExtFuncLib 

44 

dc.l DrawTriangle 

45 

dc.l GetAPen 

46 

dc.l GetBPen 

47 

dc.l -1 

48 

DataTable INITBYTE 8,9 ; Type:Library 

49 

INITLONG 10,xxxName ; LibName 

50 

INITBYTE 14,6 ; Libraryflags 

51 

INITWORD 20,Version 

52 

INITWORD 22,Revision 

53 

INITLONG 24,xxxLibID ; LiblDString 

54 

dc.l 0 ; End 

55 

InitLib movem.l al/a5,-(sp) 


56: move.l d0,a5 

57: lea.l _xxxBase(pc),al 

58: move.l dO,(al) 

59: move.l a0,34(a5) 

60: lea.l gfxname(pc),al 

61: clr.l dO 

62: jsr _LVOOpenLibrary(a6) 

63: tst.l dO 

64: beq.s InitFailed 

65: move.l d0,38(a5) 

66: move.l a5,d0 

67: Endlnit movem.l (sp)+,al/a5 

68: rts 

69: InitFailed clr.l dO 
70: bra.s Endlnit 

71: Open addq.w #1,32(a6) 

72: bclr.b #3,14(a6) 

73: move.l a6,d0 

74: rts 

75: Close subq.w #1,32(a6) 

76: btst.b #3,14(a6) 

77: beq.s EndClose 

78: bsr.s ExpugneLib 

79: EndClose rts 

80: ExpugneLib movem.l d7/al/a5/a6,-(sp) 

81: move.l a6,a5 

82: tst.w 32(a5) 

83: beq.s DiscardLib 

84: bset #3,14(a5) 

85: clr.l dO 

86: ExpEnd movem.l (sp)+,d7/al/a5/a6 
87: rts 

88: DiscardLib move.l _SysBase,a6 

89: move.l 38(a5),al 

90: jsr _LVOCloseLibrary(a6) 

91: move.l a5,al 

92: jsr _LVORemove(a6) 

93: move.l 34(a5),d7 

94: clr.l dO 

95: move.l a5,al 

96: move.w 16(a5),d0 

97: sub.l d0,al 

98: add.w 18(a5),d0 

99: jsr _LVOFreeMem(a6) 

100: move.l d7,d0 

101: bra.s ExpEnd 

102: ExtFuncLib clr.l dO 
103: rts 

104: DrawTriangle movem.l a5/a6,-(sp) ; gebra 
ute Register retten 

105: movem.l d0/dl,-(sp) ; dO und dl werden 

noch gebraucht 

106: move.l al,a5 ; RastPort aufheben 

107: move.l _xxxBase(pc),a6 ; Basis der gra 

phics.library 

108: move.l 38(a6),a6 ; holen 

109: jsr _LVOMove(a6) 

110: move.l d2,d0 

111: move.l d3,dl 

112: move.l a5,al ; RastPort zurück 

113: jsr _LVODraw(a6) 

114: move.l d4,d0 

115: move.l d5,dl 

116: move.l a5,al ; und noch einmal 

117: jsr _LVODraw(a6) 

118: movem.l (sp)+,d0/dl ; dO und dl zurück 

119: move.l a5,al ; und wieder RastPort zu 

rück 

120: jsr _LVODraw(a6) 

121: clr.l dO ; kein Returncode 

122: movem.l (sp)+,a5/a6 ; Register zurück 

123: rts 

124: GetAPen clr.l dO 
125: move.b 25(al),d0 

126: rts 

127: GetBPen clr.l dO 
128: move.b 26(al),d0 

129: rts 

130: xxxName dc.b 'xxx.library',0 
131: even 

132: xxxLibID dc.b 'Frei wählbarer Identifika 
tionsstring',13,10,0 
133: even 

134: gfxname dc.b ’graphics.library',0 

135: even 

136: _xxxBase ds.l 1 

137: End 

138: END 

139: 

140: © 1993 M&T 

»xxx.Iibrary.asm«: So programmiert 
man eine Bibliothek in Assembler 
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TIPS & TRICKS 


tolle Tools 


Programmierkniffe und -hilfen 

Tips, Tricks und 

Die Rubrik Tips & Tricks ist die meistgelesene und -begehrteste im 
AMIGA-Magazin. Jeden Monat finden Sie dort die besten Tips und 
Kniffe, die Amiga-Besitzer an die AMIGA-Redaktion schicken. Gerade 
für Programmierer gibt's dort immer ein paar Rosinen, die das Pro¬ 
grammieren auf dem Amiga erleichtern oder über - scheinbar unüber¬ 
brückbare - Hürden helfen. Auf den folgenden Seiten nun die neuesten 
- bisher unveröffentlichten - Tips... speziell für Programmierer. 


M it den Tips ist es manchmal wie mit 
Nüssen und Austern (und Wild¬ 
schweinen 1 ): die kleinen sind die 
besten. Deshalb hier nun eine Reihe von 
Tips, kurzen Programmen und Anregungen, 
die Sie in Ihren Programmen einsetzen soll¬ 
ten. Alles buntgemischt in C, Assembler 
usw., so daß für jeden etwas dabei sein sollte. 

Falls Sie selbst ein paar Tips auf Lager 
haben, mit denen Sie sich am nächsten Son¬ 
derheft »Faszination Programmieren« beteili¬ 
gen möchten, schicken Sie Ihren Beitrag mit 
allen Listings etc. auf Diskette an: 
AMIGA-Redaktion, 

Markt & Technik Verlags AG, 
Hans-Pinsel-Str. 2, 

Stichwort: Faszination Programmieren 

Viel Erfolg und natürlich viel Spaß mit den 
Tips dieser Ausgabe. 

: Quelle: Asterix als Legonär 

Mit Makros immer 
geradeaus 

Das Zeichnen von Linien über die »gra- 
phics.library« setzt normalerweise die Ver¬ 
wendung von zwei Funktionen voraus, da 
zunächst der Grafic-Cursor positioniert wer¬ 
den muß und dann erst eine Linie zu einem 
weiteren Punkt gezeichnet werden kann. Es 
handelt sich um die Funktionen »MoveO« 
und »Draw()«. Beide können durch eine 
Hilfsfunktion zusammengefaßt werden, um 
Linien mit einem Aufruf zu zeichnen, was 
auch z.B. in AmigaBASIC möglich ist: 
void DrawLine(rp,xl,yl,x2,y2) 
struct RastPort rp; 

SHORT xl,yl # x2,y2; 

{ Move(rp,xl,yl); Draw(rp,x2,y2); } 

Neben dem Anfangs- und Endpunkt, also 
(xllyl) und (x2,y2), muß der Rastport über¬ 
geben werden, in den die Linie gezeichnet 
werden soll. An den Rastport gelangt man 
über die Window-Struktur, die für jedes 
Intuition-Fenster existiert und die man beim 
Öffnen mit »OpenWindowO« erhält: 
RastPort=IrgendEinWindow->RPort; 

Christoph Brühann 


Boolean-Variable mit 
Makro toggeln 

Variable vom Typ »boolean« (kurz BOOL) 
können immer nur den Wahrheitswert TRUE 
(1) oder FALSE (0) enthalten. Manchmal 
muß der Inhalt einer solchen Variablen 
getoggelt werden, d.h. abhängig vom Zustand 
wird von TRUE nach FALSE oder umge¬ 
kehrt von FALSE nach TRUE gewechselt. 
Für diesen Schritt ist eine IF-ELSE-Anwei- 
sung naheliegend, die den Zustand abfragt 
und die Variable dann je nach Ergebnis mit 
dem anderen Wahrheitswert beschreibt. 

Mit folgendem Markro geht es durch Ver¬ 
wendung des Bedingungsoperators »?« 
jedoch wesentlich eleganter: 

#define ToggleBool(a) a = a ? FALSE : TRUE 

Der Bedingungssoperator hat allgemein 
den Aufbau: 
opl ? op2 : op3 

Das Ergebnis des Ausdrucks ist dabei 
abhängig vom Operator opl. Ist er ungleich 
Null, erhält das Ergebnis des gesamten Aus¬ 
drucks den Wert von op2, ansonsten von op3. 
Überträgt man das auf ToggleBool(), wird 
die Arbeitsweise des Makros deutlich. 

Christof Brühann/irw 


Speicher reservieren 
mit System 

Speicher reservieren unter Kickstart V2.0: 
Unter Kickstart VI.3 ist es üblich, Speicher 
mit der Funktion »AllocMemO« zu reservie¬ 
ren und mit »FreeMemO« wieder freizuge¬ 
ben. Mit Kickstart V2.0 sind die Funktionen 
»AllocVecO« sowie »FreeVecO« hinzuge¬ 
kommen, die im wesentlichen das gleiche 
bewirken, jedoch noch einen entscheidenden 
Vorteil besitzen: Beim Reservieren über 
»AllocVecO« hält der Amiga die Größe des 
Speicherblocks fest, so daß die Freigabe 
unter Weglassung der Größe geschehen kann. 


Dadurch wird nicht nur der Programmierauf¬ 
wand geringer, sondern es werden auch Feh¬ 
ler beim Freigeben durch falsche Speicher¬ 
größen ausgeschlossen. 

Die Parameter bei »AllocVecO« haben 
sich gegenüber »AllocMemO« nicht geän¬ 
dert, die Umstellung ist deshalb einfach. Man 
muß beim Freigeben lediglich darauf achten, 
daß »FreeVecO nur der Zeiger auf den frei¬ 
zugebenen Speicherblock zu übergeben ist. 

Christof Brühann/irw 


»SizeDIR« zeigt echte 
Größe 

Das folgende Listing »SizeDIR.c« ermög¬ 
licht Ihnen die Bestimmung der Größe eines 
Verzeichnisses, wobei sämtliche Unterver¬ 
zeichnisse mit beliebiger Tiefe berücksichtigt 
werden. 


Name der Quelldatei: SizeDir.c 

Aufruf mit DICE: dcc SizeDir.c -o SizeDir 

Name des ausführbaren Programms: SizeDir 

1 

/* SizeDir.c - von Christof Brühann 

2 

Aufruf mit DICE: dcc SizeDir.c -o SizeDir 

3 

SizeDir <Verzeichnis> */ 

5 

#include <libraries/aos.h> 

6 

#include <exec/memory.h> 

7 

8 
9 

ULONG size=0,numdirs=l,numfiles=0; 

BOOL SizeDir(path) 

10 

/* Bestimmt Größe eines Verzeichnisses */ 

11 

UBYTE *path; /* mit Unterverzeichnissen V 

12 

{UBYTE nxtpath[50]; 

13 

/* Pfad für nächstes Unterverzeichnis */ 

14 

struct FileLock *lock; 

15 

struct FilelnfoBiock *fib; 

16 

if (fib=(struct FilelnfoBiock *)AllocMem(siz 
eof(struct FilelnfoBiock),MEMF_PUBLIC)) 

17 

/* Speicher für FilelnfoBiock besorgen */ 

18 

(if (lock=(struct FileLock *)Lock(path,ACCES 
S_READ)) 

19 

/* Lock auf zu untersuchendes Verzeichnis */ 

20 

(if (Examine(lock,fib)) /* mehr Info */ 

21 

(while (ExNext(lock,fib)) 

22 

/* nächster Verzeichniseintrag */ 

23 

(numfiles++; /* Zähler für Dateien */ 

24 

size+=fib->fib_Size; /* Größe erhöhen */ 

25 

if (fib->fib_DirEntryType>0) 

26 

/* Unterverzeichnis ? */ 

27 

(numfiles--; /* dann neuen Pfad er- */ 

28 

numdirs++; /* stellen und SizeDir() */ 

29 

strepy(nxtpath,path); /* aufrufen */ 

30 

streat(nxtpath,fib->fib_FileName); 

31 

strcat(nxtpath,"/*); 

32 

SizeDir(nxtpath); 

33 

} 

34 

} 

35 

} 

36 

37 

38 

UnLock(lock); /* Lock wieder freigeben*/ 

\ 

/ 

eise return(FALSE ); 

39 

/* Lock konnte nicht besorgt werden */ 

40 

FreeMem(fib,sizeof(struct FilelnfoBiock)); 

41 

/* Speicher für Fileinfo frei */ 


Faszination Programmieren Nr. 1 
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42 

} 

43 

return(TRUE); 

44 

} 

45 

void main(argc,argv) 

46 

SHORT arge; 

47 

UBYTE **argv; 

48 

{ 

49 

UBYTE path[50]; 

50 

path[0]=0; 

51 

if (argol) /* Parameter vorhanden ? */ 

52 

{ 

53 

strepy(path,argv[l]); 

54 

printf ('\nBestimme Größe vom Verzeichnis '% 
s' .\n\n\argv[l]); 

55 

if (path[strlen(argv[1] )-l] !=':') strcat(pa 
th,"/")? 

56 

} 

57 

eise printf ('\nBestimme Größe vom aktuellen 
Verzeichnis.\n\n*); 

58: if (SizeDir(path)) /* Hauptfunktion aufruf 

en */ 

59: { /* und Ergebnisse ausgeben */ 

60: printf("%d Bytes wurden mit %d Dateien in % 

d Verzeichnis',size,numfiles, 

61 

numdirs); 

62 

if (numdirs>l) printf("sen"); 

63 

printf(' erreicht.\n\n"); 

64 

) 

65 

eise printf('Zugriff auf Verzeichnis *%s* ni 
cht möglich.\n\n',argv[l]); 

66: } 

67: © 1993 M&T 

»SizeDir«: Das Programm ermittelt die 

Gesamtgröße eines Verzeichnisses 


Sie können dem Programm ein Verzeich¬ 
nis, dessen Größe bestimmt werden soll, als 
Parameter übergeben. Es kann aber auch das 
bei Programmaufruf aktuelle Verzeichnis 
herangezogen werden, wenn kein Parameter 
angegeben wird. 

»SizeDir« errechnet die Größe jeder ein¬ 
zelnen Datei und addiert sie zur Gesamt¬ 
größe. »SizeDir« arbeitet mit einem rekursi¬ 
ven Algorithmus. Er ermöglicht es, in eine 
beliebig tiefe Verzeichnisstruktur zu steigen, 
was im DICE-Listing »SizeDir.c« mit der 
Funktion »SizeDirO« erreicht wird. Beim 
Untersuchen der einzelnen Verzeichnisein¬ 
träge mit den entsprechenden DOS-Funktio- 
nen prüfen wir für jeden Eintrag, ob er für ein 
Verzeichnis steht. Bei Verzeichnissen wird 
dann die Funktion »SizeDirO« einfach 
nochmal aufgerufen, und zwar mit dem 
neuen Unterverzeichnis als Parameter. In die¬ 
sem Aufruf gehen wir genauso vor wie beim 
ersten Mal, wobei auch hier bei Unterver¬ 
zeichnissen gleichermaßen verfahren wird. 

Ch ristof Brühann/i rw 


Es muß nicht immer 
PRT: sein 


Bei den meisten Ein- und Ausgaben stellt 
das Betriebssystem Devices zur Verfügung, 
um ein multitaskinggerechtes Arbeiten zu 
ermöglichen. Für den Drucker gibt es bei¬ 
spielsweise das sog. Printer-Device, welches 
die Ausgabe sowohl von Grafiken als auch 
Texten erlaubt. Doch was das Drucken von 
Texten betrifft, ist das Printer-Device pro¬ 
grammtechnisch gar nicht nötig, wodurch das 
relativ aufwendige Erstellen von Message- 
Port und Device-Block entfällt. 


Die Lösung liefert die »DOS.library«, die 
alle Funktionen zur Ein- und Ausgabe ent¬ 
hält. Der Trick besteht aus dem richtigen Öff¬ 
nen des benötigten File-Handles mit der 
Funktion »OpenO«. Als Name wird hier 
nämlich einfach der Name PRT: angegeben, 
als Modus MODE.OLDFILE: 
filej?rt=(struct FileHandle *) 

Open("prt:",MODE_OLDFILE); 

Mit dem nun vorhandenen File-Handle 
können Sie alle gewünschten Ausgaben zum 
Drucker schicken, was mit DOS wie gewöhn¬ 
lich mit der Funktion »WriteO« geschieht 
und für einen String so aussieht: 
Write(file_prt,String,strlen(String); 

Übrigens halten wir beim Drucken über 
DOS die Programmierkonventionen ein, 
obwohl das Printer-Device - scheinbar - 
nicht benutzt wird. Tatsächlich jedoch setzt 
der Amiga es ein, weil »PRT:« die DOS- 
Kennzeichnung für das Printer-Device ist. 
Versuchen Sie aber auch ruhig, »PAR:« statt 
»PRT:« einzusetzen. Christof Brühann/irw 



Fonts in jeder belie¬ 
bigen Größe 

Die »diskfont.library« bietet ab V.36 die 
Möglichkeit, Pixelfonts auch zu vergößeren 
oder zu verkleinern. Das aber verhindert ein 
Programm mit gesetztem FPF_DESIGNED. 
Des weiteren sind viele Programme so ausge¬ 
legt, daß ihr Fontmenü nur die Auswahl der 
vom System gemeldeten Größen zuläßt (kein 
AFF_SCALED). Als Abhilfe erzeugt man 
den Font in der gewünschten Größe. 

Geben Sie hierzu in ein Shell-Fenster 
SetFont <Name> <Größe> SCALE [PROP] 
ein. Die Option PROP ist nur für Proportio- 
nal-Fonts (z.B. ruby) erforderlich. 

Der Befehl SetFont ist nur für das Shell-Fen¬ 
ster, in dem er aufgerufen wird, gültig. Die 
Standardtexteinstellung im Font-Editior wird 
für dieses Fenster außer Kraft gesetzt, das 
Fenster gelöscht und die Eingabeaufforde¬ 
rung erscheint in der neuen Schriftart. 
Anschließend lädt man den skalierten Font in 
den Font-Editor »FEd« (befindet sich auf der 
Extras 1.3-Disk) mit dem Aufruf 


Extrasl.3D:Tools/FEd 

und speichert ihn. Damit steht diese Größe 
auch als Pixel-Font im Verzeichnis FONTS: 
zur Verfügung. Arno Eigenwillig/irw 

Ergänzung durch die Redaktion: Mit der Batch-Datei 
»fontsize.bat« läßt sich der Ablauf automatisieren. 


.key font,size 

setfont <font> <size> SCALE PROP 
echo 'Das ist:" <font> <size> 
if exists 'Extrasl.3D:Tools/FEd' then 
Extrasl.3D:Tools/FEd 
setfont topaz 8 
eise 

setfont topaz 8 

echo '*n Extrasl.3D:Tools/FEd nicht gefunden *n" 
endif ; © 1993 M&T 

»fontsize.bat«: Befehlsdatei, um Fonts in 
beliebiger Größe zu erzeugen 


Referenzparameter 

inC 


Beim Aufrufen von Funktionen mit Para¬ 
metern in einer Hochsprache werden i.a. die 
übergebenen Variablen nicht von der aufge¬ 
rufenen Funktion geändert. Anders bei soge¬ 
nannten Referenzparameter; in der Sprache 
Pascal durch das Schlüsselwort »VAR« 
gekennzeichnet. Hier wird für die angege¬ 
bene Variable in der aufgerufenen Funktion 
kein neuer Speicherplatz reserviert, es gibt 
somit keine lokale Variable innerhalb der 
Funktion. Stattdessen ist die übergebene 
Variable in der Funktion dieselbe wie im auf¬ 
rufenden Teil, d.h. bei Änderungen des 
Variableninhalts ist nach Beendigung der 
Funktion die Variable im aufrufenden Teil 
ebenso geändert. Die in Pascal verbreitete 
Benutzung von Referenzparametern läßt sich 
auch auf die Sprache C übertragen. Zwar exi¬ 
stiert hier kein eigenes Schlüsselwort, doch 
sind Referenzparameter in C möglich. Das 
Prinzip besteht darin, die Adresse der Varia¬ 
blen zu übergeben, da so auch von der aufge¬ 
rufenen Funktion auf die Variable zugegrif¬ 
fen werden kann. Dazu braucht vor dem 
Parameter nur der Adressoperator stehen: 
main() {SHORT i; IrgendEineFunktion(&i);} 

Nun muß im Kopf der aufgerufenden 
Funktion natürlich noch gekennzeichnet 
werden, daß nicht der Inhalt einer SHORT- 
Variable, sondern die Adresse auf so eine 
Variable übergeben wurde: 
void IrgendEineFunktion(j) SHORT *j; (...) 

Die Variable, die nicht wie im aufrufenden 
Teil heißen muß, enthält nun die Adresse auf 
unsere SHORT-Variable. Beim Zugriff auf 
die Variable muß das beachtet werden, und 
zwar muß beim Beschreiben der Inhaltsope¬ 
rator eingesetzt werden: 

*j = 42; 

Schließlich soll ja die Adresse auf die 
Variable nicht geändert werden, sondern 
lediglich ihr Inhalt. Dieser ist wiederum iden¬ 
tisch mit dem Inhalt der Variable i aus dem 
main-Teil, womit das Problem der Benutzung 
von Referenzparameter in C gelöst ist. 

Christof Brühann 
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Warum »DateTime«? Weil einige Pro¬ 
gramme die Workbench beim Start schließen 
wollen und das mit den anderen Uhren nicht 
schaffen, weil ein Window geöffnet ist. 

Daß manchmal die Workbench geschlos¬ 
sen werden muß, merkt man z.B. am Pro¬ 
gramm Populous II. Wenn bei diesem Pro¬ 
gramm die Workbench nicht geschlossen 
werden kann, treten Fehlfunktionen auf. 
Bevor man Populous II aufruft, muß man 
daher erst immer das Fenster mit der Uhr 
schließen und nach dem Beendigen des 
Spiels die Uhr wieder laden. 

Das Programm wurde unter OS 1.3 und 
OS2.0 getestet. Andreas Baum/irw 


Immer die richtige 
Zeit mit DateTime 


Es gibt nicht nur Uhrensammler, es gibt 
auch Sammler von Uhrenprogrammen. Hier 
ist eines für die Sammlung: 

»Date-Time« zeigt das Datum und die 
Uhrzeit nicht in einem Fenster, sondern in 
der Workbench-Titelzeile. 


Quelldatei: Date-Time.c 

Aufruf mit DICE: siehe Listing 

Ausführbares Programm: siehe Listing 

1 

/* Date-Time.c 

2 

* 06.10.92 by Andreas Baum 

3 

* Das Programm erzeugt eine Datums- und Uhr- 

4 

* anzeige in der Titelzeile des Workbench- 

5 

* bildschirms. Das hat den Vorteil, daß 

6 

* Programme, die den Workbenchbiidschirm 

7 

* schließen wollen, auf kein offenes Fenster 

8 

* treffen, wie es bei anderen Uhren 

10 

* Compiler DICE Version 2.06.38 

11 

* Compileraufruf: 

12 

* dcc -oRAM:Date-Time Date-Time.c 

13 

* ProgramsTiaufruf: 

14 

* 1. Workbench : Doppelklick auf Icon 

15 

* ( mit IconEdit erzeugen [ TOOLICON ] ) 

16 

* 2. CLI / Shell : Run >NIL: Date-Time 

17 

* Ein erneuter Aufruf beendet das Programm*/ 

18 

19 

20 

#include <intuition/intuition.h> 

21 

#include <intuition/intuitionbase.h> 

22 

#include <exec/execbase.h> 

23 

tfinclude <exec/memory.h> 

24 

tfinclude <workbench/startup.h> 

25 

#include <time.h> 

26 

27 

extern struct IntuitionBase *IntuitionBase; 

28 

extern struct ExecBase *SysBase; 

29 

extern struct WBStartup *_WBMsg; 

30 

31 

struct Screen *scr, *scrl; 

32 

struct Window *win; 

33 

struct Task *task; 

34 

struct tm *zeit; 

35 

36 

struct NewWindow nwin= 

37 

{0,11,250,11,0,1,NULL, 

38 

ACTIVATE1RMBTRAP,NULL,NULL,NULL,NULL,NULL, 

39 

0,0,0,0,WBENCHSCREEN 

40 

}; 

41 

42 

UBYTE buff[80], buffl[25]; 

43 

UBYTE taskname[10] = "D-T.0001"; 

44 

UBYTE winnaml[27]="DATE-TIME BY ANDREAS BAUM* 

45: UBYTE winnam2[28]="THANKS FOR ÜSING DATE-TIME 

46 

_main() 

47: {UBYTE x=0, y=0, ver; 


48: if ( FindTask ( "D-T.0001" ) == 0 ) 

49: { task = ( struct Task * ) FindTask ( NUL 

L ); 

50: task->tc_Node.ln_Name = taskname; 

51: nwin.Title = winnaml; 

52: win = ( struct Window * ) OpenWindow ( 

&nwin ); 

53: scr - win->WScreen; 

54: Delay ( 80 ); 

55: CloseWindow ( win ); 

56: if ( SysBase->LibNode.lib_Version < 37 ) 

57: ver = 1; 

58: eise 

59: ver = 2; 

60: FOREVER 

61: { time_t just; 

62: time ( fcjust ); 

63: zeit = localtime ( &just )? 

64: for { y = 0 ; y < 15 ; y++ ) 

65: { if ( ( Strien ( scr->Title ) < 6 

5 II zeit->tm_min != x ) && ( strncmp ( scr-> 
Title, "Amiga Workbench ", 17 ) == 0 II strn 
cmp ( scr->Title, "Workbench release.", 18 ) 
« 0)1 

66: { x = zeit->tm_min; 

67: strftime ( buffl, 25, "%d %b 

%y %H:%M", zeit ); 

68: if ( ver == 1 ) 

69: sprintf ( buff, "Workbench 

release. Id free memory Is", AvailM 
em ( MEMF.PUBLIC ), buffl); 

70: eise 

71: sprintf ( buff, "Amiga Work 

bench Id graphics mem Id other mem %s\ Av 
ailMem ( MEMF.CHIP ), AvailMem ( MEMF_FAST ), 
buffl); 

72: scr->Title = buff; 

73: ShowTitle { scr, TRUE ); 

74: } 

75: Delay ( 10 ); 

76: ) 

77: scrl = IntuitionBase->ActiveScreen; 

78: if ( scrl != scr ) 

79: { 

80: if ( strncmp ( scrl->Title, " 

Workbench Screen", 16 ) == 0 II strncmp ( scr 
l->Title, "Amiga Workbench • ,17 ) == 0 II s 
trncmp ( scr->Title, "Workbench release.*, 18 
) » 0 ) 

81: scr = scrl; 

82: } 

83: } 

84: } 

85: eise 

86: { 

87: ForbidO; 

88: RemTask ( FindTask ( "D-T.0001" ) ); 

89: PermitO; 

90: 

91: nwin.Title = winnam2; 

92: win = ( struct Window * ) OpenWindow 

( &nwin ); 

93: Delay ( 80 ); 

94: CloseWindow ( win ); 

95: 

96: exit ( 0 ); 

97: } 

98: _waitwbmsg(); 

99: > © 1993 M&T 

Date-Time.c: Hiermit zeigt der Amiga 
die Uhrzeit in der Titelzeile 


Speicher grafisch 
sichtbar machen 


Das Programm »MemoryViewer.c« macht 
den Speicher grafisch sichtbar. Mehr noch: 
Durch Bewegungen eines am Gameport 2 
angeschlossenen Joysticks können Sie den 
Workbench-Screen verschieben und der 
angrenzende Speicherbereich wird sichtbar. 
So lassen sich sogar im Speicher befindliche 
Bilder betrachen. Ein Druck auf den Feuer¬ 
knopf stellt den Workbench-Screen wieder 
her und beendet das Programm. O 


Quelldatei : MemoryViewer.c 
Aufruf mit DICE: 

dcc MemoryViewer.c -o MemoryViewer 
Ausführbares Programms: MemoryViewer 


1: /* MemoryViewer.c 

2: Mit DICE: dcc MemoryViewer.c -o MemoryViewer 
3: Start: MemoryViewer 

4: */ 

5: #inciude <intuition/intuitionbase.h> 

6: #include <graphics/gfxbase.h> 

7: tinclude <graphics/view.h> 

8: #include <graphics/rastport.h> 

9: #include <hardware/custom.h> 

10: #include <hardware/cia.h> 

11: #define custom (*((struct Custom *)0xdff000)) 
12: #define ciaa (*((struct CIA *)0xbfe001J) 

13: #define M0D(a,b) (a-a/b*b) 

14: struct IntuitionBase *IntuitionBase; 

15: struct GfxBase ‘GfxBase; 

16: struct ViewPort *ViewPort; 

17: PLANEPTR OldPlanes[4]; 

18: 

19: void main() 

20 : { 

21: struct BitMap ‘BitMap; 

22: USHORT i,width,joydat,button; 

23: GfxBase=(struct GfxBase *)OpenLibrary("graph 
ics.library",0); 

24: /* Libraries öffnen */ 

25: IntuitionBase=(struct IntuitionBase *)OpenLi 
brary(*intuition.library",0); 

26: ViewPort=(struct ViewPort *)ViewPortAddress( 
IntuitionBase->ActiveWindow); 

27: /* BitMap des Screens ermitteln */ 

28: BitMap=ViewPort->RasInfo->BitMap; 

29: for (i=0;i<4;i++) OldPlanes(i)=ViewPort->Ras 
Info->BitMap->Planes[i]; 

30: /* Adressen der Bitplanes sichern */ 

31: if (MOD(ViewPort->DWidth,16)) width=(ViewPor 
t->DWidth/16+1)*4; 

32: eise width=ViewPort->DWidth/4; 

33: /* Breite der Planes in Bytes bestimmen */ 

34: ForbidO;/‘nicht mehr in Planes schreiben*/ 
35: do 

36: {joydat=custom.joyldat; 

37: /* Datenregister für Joystick 1 auslesen */ 
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38 

if (joydat&2) /* Bewegung nach rechts ? */ 

39 

(ViewPort->DxOffset++; 

40 

/* Viewport um einen Pixel verschieben */ 

41 

if (ViewPort->Dx0ffset==16) 

42 

/* beim nächsten Datenwort Adresse der */ 

43 

{ /* Planes ändern */ 

44 

for (i=0;i<4;i++) BitMap->Planes[i]-=2; 

45 

ViewPort->DxOffset=Q; 

46 

} 

47 

} 

48 

if (joydat&512) /* Bewegung nach links ? * 

49 

{ViewPort->DxOffset--; 

50 

if (ViewPort->Dx0ffset==-16) 

51 

{ViewPort->DxOffset=0; 

52 

for (i=0;i<4;i++) BitMap->Planes[i]+=2; 

53 

} 

54 

} 

55 

if (((joydat&l)=l) A ( (custom. joyldat&2)==2) 

t 

56 

/* Bewegung nach unten */ 

57 

for (i=0;i<4;i++) ViewPort->RasInfo->BitMa 
p->Planes[ij-=width; 

58: if (((joydat&256)==256) A ((joydat&512)==512) 

59 

/* Bewegung nach oben */ 

60 

for (i=0?i<4;i++) ViewPort->RasInfo->BitMa 
p->Planes[i]+=width; 

61 

ScrollVPort(ViewPort); 

62 

/* Viewport neu darstellen */ 

63 

button=ciaa.ciaDra; 

64 

} while (button&CIAF.GAMEPORTl); 

65 

/* Feuerknopf ? */ 

66 

for (i=0;i<4;i++) ViewPort->RasInfo->BitMap- 
>Planes[i]=01dPlanes[ i ]; 

67 

/* Ausgangszustand wiederherstellen */ 

68 

ViewPort->DxOf fset=0; 

69 

ViewPort->DyOffset=0; 

70 

ScrollVPort(ViewPort); 

71 

Permit(); 

72 

} 

73 

© 1993 M&T 

Listing: Diff.c: Das C-Programm leitet 

einen mathematischen Ausdruck ab 


Die Basis des Programms wird durch die 
Funktion »ScrollVPort« der »graphics.li- 
brary« gebildet. Die Funktion stellt den 
Viewport neu dar, wobei Veränderungen in 
der Viewport-Struktur berücksichtigt werden. 

Ausgehend vom Viewport, der die Work- 
bench darstellt, werden je nach Joystick- 
Bewegung der Eintrag »DxOffset« oder die 
Bitplane-Adressen geändert und es entsteht 
eine Verschiebung des Screens. Bei Bewe¬ 
gungen nach links oder rechts wird zunächst 
nur der Eintrag »DxOffset« geändert. 
Erreicht »DxOffset« den Umfang eines 
Datenworts (16 Punkte), setzt der Amiga den 
Offset auf 0 zurück und ändert dafür die 
Adressen der Bitplanes um die entsprechende 
Anzahl von Bytes. 

Bewegt man den Joystick nach oben oder 
unten, werden einfach die Bitplane-Adressen 
um die Breite des Viewports in Bytes erhöht 
beziehungsweise erniedrigt. 

Die Bitplane-Adressen sind in der Bitmap- 
Struktur eingetragen, welche über 
Viewport->RasInfo->BitMap 
besorgt wird. 

Weil das Programm die Adressen der Bitpla¬ 
nes ändert, darf nichts in den Rastport 
geschrieben werden, so lange ein unbekann¬ 
ter Speicherbereich angezeigt wird. Andern¬ 
falls überschriebe der Amiga unbekannte 
Speicherstellen. Deshalb wird das System - 
ausnahmsweise mal - mit »ForbidO« ange¬ 
halten, bis wir am Ende des Programms den 
Ausgangszustand wiederherstellen. 

Ch ristof B rü hann/i rw 


Sortieren nach der 
Zeit 


Einige Amiga-Anwender werden sicherlich 
ein Programm vermissen, daß ein Verzeich¬ 
nis nach Zeit sortiert ausgibt. Der bereits vor¬ 
handene CLI-Befehl LIST erlaubt zwar eine 
sortierte Ausgabe, allerdings besteht nur die 
Möglichkeit, die Dateien nach ihren Namen 
zu sortieren, was durch das Programm »Sort- 
ByDate.c« geändert werden soll. 

Quelldatei : SortByDate.c 

• Aufruf mit DICE: siehe Listing 

Ausführbares Programms: siehe Listing 

1: /‘SortByDate.c - von Christof Brühann 

2 

Betriebssystem: Kickstart V2.04 

3 

Kompilieren mit DICE: 

4 

5 

6 

dcc SortByDate.c -o SortByDate */ 

#include <dos/dos.h> 

7 

#include <exec/memory.h> 

8 

Sinclude <time.h> 

9 

#include <dos/var.h> 

10 

Ddefine FIBSIZE sizeof(struct FilelnfoBlock) 

11 

char *mon[] = {"Jan\ "Feb\ "Mär\ "Apr*, *Mai\ * 
Jun\ "Jul\ "Aug\ 'Sep\ *0kt\ "Nov\ 'Dez'}; 

12 

UBYTE dir[255] = {0>; 

13 

struct FilelnfoBlock *fib,*fibptr[250]; 

14 


15 

void UsageO /* Info über Aufruf ausgeben */ 

16 

{ 

17 

printfC\nSortByDate [<verzeichnis>] [<anza 
hl>]\n\n'); 

18: printf(*<verzeichnis> - auszugebenes Verzei 
chnis (Voreinstellung: aktuelles '); 

19 

puts(■'Verzeichnis)"); 

20: printf("<anzahl> - Anzahl auszugebener 

Einträge (Voreinstellung: alle)'); 

21 

printf C\n\n*); 

22 

} 

23 

void main(argc,argv) 

24 

SHORT arge; 

25 

UBYTE **argv; 

26 

{ 

27 

LONG num21ist=250,numall=0,i,j; 

28 

time_t secs; 

29 

struct tm *tm; 

30 

struct Lock ‘lock; 

31 

APTR mem; 

32 

if (strcmp(argv[l],"?')==0 II argc>3) üsage 
0; 

/* ggf. Programminfo ausgeben */ 

33 

34 

eise 

35 

{ 

36 

if (argc==2) /* Parameter untersuchen*/ 

37 

if (sscanf(argv[l], *%d\&num21ist)==-l) 

38 

/* und Variablen für */ 

39 

{ /* Verzeichnis und Anzahl*/ 

40 

num21ist=250; /* beschreiben */ 

41 

strcpy(dir,argv[l]); 

42 

43 

} 

44 

if (argc==3) /‘zwei Parameter vorhanden?*/ 

45 

{ 

46 

if (sscanf(argv[lj,"%d",&num21ist)==-l) 

47 

{ 

48 

strcpy(dir,argv(l]); 

49 

num21ist=0; 

50 

sscanf (argv[2], "%d\&num21ist); 

51 

) 

52 

eise strepy(dir,argv[2]); 

53 

) 

54 

if (num21ist<l) UsageO; 

55 

mem=(APTR)AllocMem(num21ist*FIBSIZE,MEMF P 
UBLIC); 

56 

/* Speicher für Verzeichniseinträge */ 

57 

fib=(struct FilelnfoBlock *)AllocMem(FIBSI 

ZE,MEMF_PUBLIC); 

58 

if (memä&fib) /* genug Speicher? */ 

59 

{ 

60 

for (i=0;i<num21ist;i++) fibptr[i]=mem+i* 
FIBSIZE; 

61 

/*Zeiger->Verzeichniseinträge beschreiben*/ 

62 

if (lock=(APTR)Lock(dir,ACCESS.READ)) 


63 

/* Lock auf Verzeichnis holen */ 

64 

( 

65 

if (Examine(lock,fib)) 

66 

/* nähere Infos über Verzeichnis */ 

67 

if (fib->fib_DirEntryType>0) 

68 

/‘Parameter für Verzeichnis eine Datei? */ 

69 

{ 

70 

while (ExNextdock, fib)) 

71 

/* nächster Eintrag */ 

72 

{ 

73 

numall++; 

74 

/* Zähler für gefundene Einträge */ 

75 

if (numall==l) memepy(fibptr[0],fib,F 
IBSIZE); 

76 

eise 

77 

{ 

78 

j=num21ist; 

79 

if (numall<num21ist) j=numall; 

80 

for (i=0;i<j;i++) 

81 

/* Eintrag in vorhandene Liste einordnen:*/ 

82 

( 

83 

if (CompareDates(&fibptr[i]->fib_Date,&fib 
->fib_Date)>=0) 

84 

/* bzgl. Revisionsdatum vergleichen */ 

85 

{ 

86 

memepy(fibptr[i+1],fibptr[i],(j-i-l)*FIBS 
IZE); 

87 

/* einordnen */ 

88 

memepy(fibptr[i],fib,FIBSIZE); 

89 

i=-l; 

90 

break; 

91 

} 

92 

) 

93 

if ((i!=-l) && (numall<=num21ist)) 

94 

memepy(fibptr[numall-1],fib,FIBSIZE); 

95 

) 

96 

} 

97 

j=num21ist; 

98 

/* Ausgabe der sortierten Liste: */ 

99 

if (numall<num21ist) j=numall; 

100 

for (i=j-l;i>=0;i—) 

101 

{ 

102 

printf{"%-25s *,fibptr[i]->fib_Fi 

leName); 

103: 

: if (fibptr[i]->fib_DirEntryType>0) pr 

intf("%7s","Dir'); 

104: 

: eise printf("%7d',fibptr[i]->fib_Size); 

105: secs=fibptr[i]->fib_Date.ds_Days*(144 

0*60)+fibptr[i]->fib_Date.ds_Minute* 

106 

60+fibptr[i]->fib_Date.ds_Tick/50; 

107 

/* Umwandlung von DateStamp nach Sekunden*/ 

108 

tm=localtime(&secs); 

109 

/* tm-Struktur ausfüllen lassen */ 

110 

printf(' %02d.%3s.%02d %02d:%02d:%0 
2d",tm->tm_mday,mon[tm->tm_mon], 

111 

tm->tm_year,tm->tm_hour,tm->trunin,tm 
->tm_sec); 

112 

printf C\n"); 

113 

} 

114 

printf("%d von %d Einträgen ausgegeben 
.\n\ j,numall); 

115 

} 

116 

eise printf ("%s' ist kein Verzeichnis 
!\n",fib->fib_FileName); 

117 

UnLock(lock); 

118 

1 

119 

eise puts("Falsches Verzeichnis !'); 

120 

} 

121 

if (mem) FreeMem(mem,num21ist*FIBSIZE); 

122 

if (fib) FreeMem(fib,FIBSIZE); 

123 

} 

124 

} ; © 1993 M&T 

»SortByDate.c«: Sortierte Ausgabe eines 

Verzeichnisses per C-Programm 


Der Aufruf dieses in C verfaßte Pro¬ 
gramms lautet: 

SortByDate [<verzeichnis>] [<anzahl>] 

Beide Parameter sind optional. Der erste 
gibt das Verzeichnis an, das ausgegeben wer¬ 
den soll, wobei bei fehlender Angabe das 
aktuelle Verzeichnis verangezogen wird. Soll 
das gesamte Verzeichnis ausgegeben werden, 
kann der zweite Parameter weggelassen wer¬ 
den. Möchte man jedoch nur eine bestimmte 
Anzahl der neusten Einträge ausgeben, kann 
das mit diesem Parameter getan werden. So 
ist es z.B. möglich, durch Angabe von 1 nur 
die zuletzt bearbeitete Datei auszugeben. 
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Beim Listen wird neben dem Namen auch 
die Größe des Eintrags in Bytes sowie der 
Zeitpunkt der letzten Bearbeitung ausgege¬ 
ben. Verzeichnisse können durch die Ken¬ 
nung »Dir« anstelle der Größe von Dateien 
unterschieden werden. »SortByDate« richtet 
sich zur Ermittlung des letzen Bearbeitungs¬ 
zeitpunkts nach der DateStamp-Struktur, die 
im FilelnfoBlock eingetragen ist. Diese wird 
bei jedem Schreibzugriff vom Betriebssystem 
automatisch modifiziert. Da man an den 
FilelnfoBlock sowieso immer dann gelangt, 
wenn ein Verzeichnis über Examine() und 
ExamineNext() ausgegeben wird, ist das 
Beschaffen dieses Datenblockes für die ein¬ 
zelnen Einträge kein Problem. Jeder gefun¬ 
dene Eintrag wird in eine Liste geschrieben. 
Sollte ein Eintrag wegen seines Bearbei¬ 
tungsdatums nicht ans Ende der Liste ange¬ 
fügt werden können, muß dieser einsortiert 
werden. Dies wird erreicht, indem alle Ein¬ 
träge hinter der entsprechenden Postion nach 
hinten -verschoben werden, so daß der neue 
Eintrag anschließend direkt an die richtige 
Position geschrieben werden kann. Mit die¬ 
sem Verfahren sind bereits alle Einträge sor¬ 
tiert, wenn das Verzeichnis vollständig gele¬ 
sen ist. Christof Brühann 


Der Mauszeiger bleibt 
kleben 

Im Handbuch zur System-Software 2.0 
wird im Kapitel 2-6 beschrieben, wie man 
den Amiga auch ohne Maus betreiben kann. 
Doch es gibt auch undokumentierte Funktio¬ 
nen: Halten Sie die linke Amiga-Taste und 
danach die linke Maus-Taste gedrückt (die 
Reihenfolge ist wichtig!). Die Position der 
Maus ist bedeutungslos. Nun klebt der Maus¬ 
zeiger auf dem Screen fest und kann mit der 
Maus vertikal wenn möglich auch horizontal 
verschoben werden. Felix Farago/irw 


Mit LIST und ohne 
Tücken 

Vor dem Start eines Programms vom CLI 
aus ist es oft sinnvoll, das Verzeichnis, in 
dem sich das Programm befindet, mit DIR 
oder LIST anzuschauen. Das kann verschie¬ 
dene Gründe haben: Zum einen wird so 
sichergestellt, daß das Programm auch wirk¬ 
lich im entsprechenden Verzeichnis zu finden 
ist. Zum anderen kennt man oft nicht den 
vollständigen Name des Programms, der zum 
Aufruf schließlich komplett eingegeben wer¬ 
den muß. Besonders bei neuen und deshalb 
noch nicht vertrauten Programmen, was mei¬ 
stens bei neuer Software aus dem PD-Bereich 
der Fall ist, trifft das immer wieder zu. 

In letzterem Fall weiß man oft auch nicht, 
welche Datei das Hauptprogramm ist und 
zum Start aufgerufen werden muß. Beim 
Auflisten des Verzeichnisses ist es dann 
störend, daß auch reine Daten- und Info- 
Dateien angezeigt werden. Sie bewirken nur, 
daß man den Überblick verliert. 


Name der Quelldatei : ListExecutables.c 
Übersetzen mit DICE: dcc ListExecutables.c -o 
Ausführbaren Programm: ListExecutables 


1: /* ListExecutables.c - listet alle ausführbar 
en Programme eines Verzeichnisses 
2: Aufrufe mit DICE: 

3: dcc ListExecutables.c -o ListExecutables 

4: ListExecutables <directory> 

5: *1 
6 : 

7: Sinelüde <aos/dos.h> 

8 : 

9: struct Lock *lock; 

10: struct FilelnfoBlock fib; 

11: struct FileHandle *file; 

12 : 

13: void main(argc,argv) 

14: SHORT arge; 

15: UBYTE **argv; 

16: (ULONG type; 

17: UBYTE path[255],i; 

18: if |lock=(APTR)Lock(argv[l],ACCESS_READ)) 


19 

/* Lock auf Verzeichnis holen */ 

20 

{if {Examine(lock,&fib)) 

21 

/* Info über Verzeichnis */ 

22 

if (fib.fib_DirEntryType>0) 

23 

/* war Parameter Verzeichnis ?*/ 

24 

(i=strlen(argv[l]); 

25 

I* wenn nötig, an Pfad '/' anhängen V 

26 

strepy(path,argv[1]); 

27 

if (pathli-1]' && path[i-l]!='/' && s 


trlen(argv[l])) path[i++] = 7',* 

28 

while (ExNext(lock,&fib)) 

29 

/* nächste Datei des Verzeichnisses *, 

30 

{path[i]=0; 

31 

streat(path,fib.fib_FileName); 

32 

/* Pfad mit Datei erstellen */ 

33 

if (file=(APTR)Open(path,M0DE_0LDFILE)) 

34 

/* ur.d Datei öffnen */ 

35 

{if (Read(file,&type,4)==4) 

36 

/* Dateityp prüfen und Name */ 

37 

if (type==0x3f3) /* ggf. ausgeben */ 

38 

printf ("%s\n", fib.fib_FileName); 

39 

Close(file); 

40 

} 

41 

} 

42 

} 

43 

eise printf ("is' ist kein Verzeichnis !\n 
",fib.fib_FileName); 

44 

UnLock(lock); 

45 

} 

46 

eise puts("Falsches Verzeichnis !"); 

47 

/* Parameter beschreibt kein Verzeichnis*/ 

48 

) 

49 

© 1993 M&T 

»ListExecutables.c«: Das C-Programm 
listet alle ausführbaren Programme 


Für solche Fälle ist ein Utility nützlich, das 
nur Programme auflistet, die tatsächlich 
gestartet werden können. Das DICE-Pro- 
gramm »ListExecutables.c« übernimmt die¬ 
ses Funktion. Es listet alle Dateien vom Typ 
»executable« (ausführbar) auf. 

Beim Aufruf von ListExecutables ohne 
Angabe eines Verzeichnisses wird das aktu¬ 
elle Verzeichnis oder das als Parameter ange¬ 
gebene Verzeichnis untersucht. 

Bei der Auflistung geht »ListExecutables« 
prinzipiell vor wie der normale LIST-Befehl, 
da auch hier die entsprechenden DOS-Funk- 
tionen »Lock()«, »ExamineO« sowie »Ext- 
Next()« verwendet werden. Allerdings wer¬ 
den nur die Dateien ausgegeben, die ausführ¬ 
bar sind. Sie sind daran erkennbar, daß sie 
mit einem Hunk vom Typ »Load-File« 
beginnen, welches wiederum durch ein 
»0x30« als erstes Langwort identifiziert 
wird. Christof Brühann/irw 


Parameterauswertung 
in Assembler 


Viele zusätzliche Informationen können 
bei CLI-Programmen durch die Verwendung 
von Parametern übergeben werden. Möchte 
ein Programmierer diese Möglichkeit auch 
für seine Programme nutzen, muß die richtige 
Vorgehensweise zur Auswertung der Argu¬ 
mente bekannt sein. Da in C über die Funk¬ 
tion main() mit den Parametern arge sowie 
argv bereits der Compiler das fertige Parame¬ 
ter-Array zur Verfügung stellt, fällt der 
Zugriff auf die einzelnen Argumente hier 
nicht schwer. 

Ein wenig anders ist es in Assembler, da 
hier zunächst nur der gesamte Parameter- 
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String sowie seine Länge in den Registern AO 
und DO vorhanden ist. Doch stellt das neue 
Betriebssystem V2.0 zahlreiche neue Funk¬ 
tionen zur Verfügung, welche die ganze 
Sache vereinfachen. Ziel soll es sein, daß 
jeder einzelne Parameter als String in einem 
Parameter-Array vorliegt. Auf diese Weise 
kann die Auswertung der Parameter später 
dann durch gezielte Vergleiche mit den ein¬ 
zelnen Parametern vorgenommen werden. 
Am einfachsten wird die Aufteilung des 
Parameter-Strings durch die neue Dos-Funk- 
tion Readltem() erreicht. Ausgehend von 
einem beliebigen Argument-String liest diese 
Funktion ein einziges Argument heraus und 
schreibt dieses als String in einen Puffer. 
Dabei wird der Argument-String nicht als 
einfacher String angegeben, sondern als eine 
CSource-Struktur, die folgendermaßen aus¬ 
sieht: 

struct CSource { 

UBYTE *CS_Buffer; ; Zeiger auf Puffer 

LONG CS_Length ; * ; Länge des Puffers 

LONG CS_CurChr; ; akt.Zeichenposition 

); 

In den Einträgen CS_Buffer und 
CS_Length wird die Adresse des Parameter- 
Strings sowie seine Länge eingetragen. Dabei 
können die Register AO und DO am Anfang 
des Programms direkt übernommen werden. 
Der Vorteil bei Verwendung der CSource- 
Struktur gegenüber eines einfachen Strings 
liegt im Eintrag CS_CurChr begründet, der 
immer mit der aktuellen Zeichenposition im 
Puffer beschrieben ist und anfangs den Wert 
0 bekommt. Die Funktion »ReadltemO« 
berücksichtigt nämlich beim Ablaufen diesen 
Eintrag. D.h. in der Praxis, daß das nächste 
aufzulösende Argument immer an Position 
CS_CurChr beginnt, wobei »ReadltemO« 
CS_CurChr automatisch erhöht. Zum Auflö¬ 
sen des gesamten Parameterstrings braucht 
deshalb »ReadltemO« nur solange aufgerufen 
werden, bis das Ende erreicht ist. Lediglich 
der Zielpuffer muß bei jedem Durchgang 
erhöht werden. Als Ergebnis erhält man ein 
Array mit allen Argumenten. »ReadArgu- 
ments.s« ist das zugehörige Demoprogramm. 


1: OpenLibrary: equ -552 
2: Readltem: equ -810 
3: VPrintf: equ -954 
4: ITEMSIZE: equ 40 
5: 

6: move.l aO,ArgStrg ; Zeiger auf Argument-Strin 

g 

7: move.l dO,ArgStrgLen ; und Länge retten 
8: move.l 4,a6 
9: lea DosName,al 

10: move.l #37,dO ; mindestens OS 2.0 erforderlic 
h 

11: jsr OpenLibrary(a6) ; Dos-Library öffnen 

12: tst.l dO ; V37 nicht vorhanden ? 

13: beq quit 

14: move.l dO,DosBase ; Library-Basis retten 
15: move.l ArgStrg.aO ; Parameter f. ReadArgument 
s() 

16: move.l ArgStrgLen.dO 

17: jsr ReadArguments ; ReadArgumentsO aufrufen 
18: lea param,aO ? Zahl Argumente in Param.-Array 

19: move.l Numltems,(aO) ; schreiben 
20: ; (wird für VPrintf() gebraucht) 

21-: move.l #fmsgl,dl 
22: move.l #param,d2 


23: move.l DosBase,a6 

24: jsr VPrintf(a6) ; Zahl Argumente ausgeben 
25: lea ItemArray,a3 ; Adresse des Arrays der Ar 
gumente 

26: sub.l d3,d3 

27: out_args: ; Argumente ausgeben: 

28: cmp.l Numltems,d3 ; alle Argumente ausgegeben 

29: beq quit 

30: lea param,aO ; für VPrintf{) wieder Parameter 
-Array 

31: move.l d3,(a0) ; beschreiben (mit Argumentnu 

mmer 

32: move.l a3,4(a0) ; und Adresse des Arguments 

) 

33: move.l #fmsg2,dl 
34: move.l #param,d2 

35: jsr VPrintf(a6) ; Ausgabe des Arguments 

36: add.l #l,d3 ; Argumentnummer erhöhen 

37: add.l #ITEMSIZE,a3 ; Zeiger-»nächstes Argumen 
t 

38: bra out_args ; weiter mit nächstem Argument 
39: quit: 

40: sub.l d0,d0 

41: rts 

42: 

43: ; ReadArgumentsO - unterteilt den Argument-S 
tring in die verschiedene 
44: ; Argumente und schreibt sie in das Arra 
y "ItemArray" 

45: ; Parameter: aO: Argument-String 
46: ; dO: Länge des Argument-Strings 
47: ReadArguments: 

48: movem.l d2-d3/a3/a6,-(sp) 

49: move.l DosBase,a6 

50: lea CSource,al ; Argument-String und seine L 
änge in CSource-Struktur 

51: move.l a0,(al) ; eintragen, die der Dos-Funk 

tion ReadltemO 

52: move.l d0,4(al) ; übergeben wird 

53: move.l #0,8(al) 

54: lea ItemArray,a3 ; Adresse des Argument-Array 
s 

55: clr.l Numltems ; Zähler für Anzahl der Argume 
nte 

56: read_item: 

57: move.l ArgStrgLen,d0 
58: sub.l #1,dO 
59: lea CSource,aO 

60: cmp.l 8(aO),dO ; schon fertig ? 

61: beq quit_ReadArguments 

62: move.l a3,dl ; Ziel für nächstes Argument 

63: move.l #ITEMSIZE,d2 

64: move.l #CSource,d3 

65: jsr Readltem(a6) ; nächstes Argument bestimme 
n mit ReadltemO 

66: add.l #ITEMSIZE,a3 ; Adresse nächstes Argumen 
t 

67: add.l #1,NUMITEMS ; Argumentenzähler erhöhen 
68: bra read_item ; nächste Runde 
69: quit_ReadArguments: 

70: movem.l (sp)+,d2-d3/a3/a6 

71: rts 

72: 

73: ItemArray: blk.b ITEMSIZE*50 
74: even 

75: Numltems: dc.l 0 

76: ArgStrgLen: dc.l 0 

77: ArgStrg: dc.l 0 

78: CSource: blk.b 12 

79: DosName: dc.b "dos.library",0 

80: even 

81: DosBase: dc.l 0 

82: fmsgl: dc.b 13,10,"Anzahl der Argumente: %ld 
*,13,10,10,0 
83: even 

84: fmsg2: dc.b "Argument %ld: %s",13,10,0 
85: even 

86: param: dc.l 0,0 ; 

© 1993 M&T 

»ReadArguments.s«: Beispiel für Para¬ 
meterauswertung in Assembler 


Die Hauptfunktion wird durch »ReadArgu¬ 
mentsO« gebildet. Ihr ist der Parameterstring 
in AO sowie die Länge in DO zu übergeben. 
Sie liefert als Ergebnis das Array ab Label 
»ItemArray« mit den Argumenten. 

Die maximale Größe eines Arguments 
wird mit ITEMSIZE festgegt. Das Argument 
Nummer n (n=0, 1, Numltems-1) befindet 


sich demnach an der Adresse 

ItemArray+n*ITEMSIZE 

Die Anzahl der vorhandenen Argumente 
wird in der Variable »Numltems« gespei¬ 
chert. Das Hauptprogramm gibt nach dem 
Aufruf von »ReadArgumentsO« zunächst die 
Anzahl der Argumente aus, dann die Argu¬ 
mente selbst. Bei der Ausgabe wird dabei die 
ebenfalls neue DOS-Funktion »VPrintfO« 
verwendet, welche eine formatierte Ausgabe 
einfach macht. Probieren Sie das Programm 
»ReadArguments« ruhig mal aus, indem Sie 
es vom CLI aus starten und verschiedene 
Parameter übergeben. Übrigens hat die Ver¬ 
wendung der OS-Funktion »ReadltemO« 
große Vorteile gegenüber der Programmie¬ 
rung von Hand, da »ReadltemO« alle vorhan¬ 
denen Konventionen beachtet und somit die 
Programme standardisiert. Z.B. wird durch 
ein Semikolon jeder Parameterstring beendet. 
Dadurch lassen sich Kommentare verwenden, 
was auch bei allen anderen CLI-Befehlen 
möglich ist. Außerdem wird das Gleichheits¬ 
zeichen als Leerzeichen interpretiert. Zwar 
läßt sich unter Berücksichtigung des Rückga¬ 
bewerts von ReadltemO dies unterscheiden, 
doch kann man z.B. auch beim CLI-Befehl 
LIST statt 
list s: sort 
auch 

list s:=sort 

schreiben! Zum Schluß sei noch erwähnt, daß 
mit »ReadltemO« bei Verwendung von 
Anführungsstrichen auch Argumente erlaubt 
sind, die sich aus mehreren Wörtern zusam¬ 
mensetzen, was ebenfalls standardisiert ist. 

Christof Brühann/irw 

Zeig alles , was 
Du hast 

Mit dem Hilfsprogramm »all.c« kann man 
die Wirkung von AmigaDOS-Befehlen auf 
Unterverzeichnisse ausdehnen, d.h. ein ge¬ 
wünschter Befehl wird nicht nur auf das aktu¬ 
elle oder angegebene Verzeichnis angewandt, 
sondern auch auf sämtliche Unterverzeich¬ 
nisse. Dazu durchläuft es rekursiv den ange¬ 
gebenen Verzeichnisbaum und führt die als 
Paramater übergebenen Befehle aus. 

Der Aufruf erfolgt folgendermaßen: 
all [-A] [-E] Verzeichnis Befehll [Befehl2 
Befehl3 ...] 

Der Parameter »Verzeichnis« bestimmt 
dabei den zu durchlaufenden Verzeichnis¬ 
baum. Für das aktuelle Verzeichnis kann man 
wie unter AmigaDOS üblich "" angeben. 

Mit »Befehll [Befehl2 BefehB ...]« ist die 
Befehlsfolge gemeint, die in den Verzeich¬ 
nissen des Verzeichnisbaums ausgeführt wer¬ 
den soll. Natürlich muß zumindest ein Befehl 
angegeben werden. 

Es ist zu beachten, daß unter AmigaDOS 
keine Anführungszeichen übergeben werden 
können, »all« bietet jedoch die Möglichkeit, 
anstelle eines Anführungszeichens ein Hoch¬ 
komma (<Alt ä>) zu verwenden. Damit das 
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Hochkomma selbst nicht wegfallt, stehen 
zwei aufeinanderfolgende Hochkomma für 
ein richtiges Hochkomma. Außerdem ist zu 
beachten, daß ein Befehl mit all seinen Para¬ 
metern als ein einzelner Parameter an »all« 
übergeben werden muß. Ein - wenn auch 
wenig sinnvolles - Beispiel soll diese beiden 
Punkte verdeutlichen: 
all dfO: "echo 'Hallo'" 

gibt für jedes Verzeichnis auf dfO: das Wort 
»Hallo« aus. 

Die optionalen Parameter »[-AJ [-E]« 
legen fest, in welcher Reihenfolge die Ver¬ 
zeichnisse abgearbeitet werden. Wählen Sie 
beispielsweise -E, wird mit dem Ende des 
Verzeichnisbaums begonnen; bei -A mit dem 
Anfang. -A ist voreingestellt, muß also nicht 
explizit angegeben werden. Gibt man 
all -A dfO: cd 
und danach 
all -E dfO: cd 

ein, wird der Unterschied schnell klar. 

Der Programmablauf kann natürlich durch 
<Ctrl C> abgebrochen werden. Bei einem 
Fehler oder bei einem Abbruch gibt »all« den 
Fehlercode 10 an seine Umgebung zurück, 
»all« ohne einen Parameter gibt eine gekürzte 
Version der Anleitung aus. 

Was kann man nun konkret mit dem Pro¬ 
gramm anfangen? Hierzu eine nützliche 
Batch-Datei mit Namen »FIND«: 

• key Verzeichnis/a,file/a,optl,opt2,opt3,opt4 
resident c:echo add 

. 'cd' und 'list' hat wohl jeder resident 
failat 15 

. sonst bleibt echo bei Fehler resident 
all <Verzeichnis> "echo '*E[lm' noline" cd 

"echo '*E[0m' noline" "list pat <file> 

<optl> <opt2> <opt3> <opt4> nohead" 
resident c:echo remove 

FIND durchsucht einen Verzeichnisbaum 
nach einer bestimmten Datei. Im Gegensatz 
zu anderen Programmen dieser Art geschieht 
die Ausgabe über den AmigaDOS LIST- 
Befehl. Dem Benutzer stehen somit alle 
Möglichkeiten des LIST-Kommandos offen. 
Man kann mit den Optionen von LIST leicht 
die Ausgabe beeinflussen und sämtliche 
Amiga DOS-Wildcards verwenden. Aufruf: 
FIND Verzeichnis Dateirauster [Optionen] 

Ein Beispiel: 

FIND dfO: d#? 

Der Aufruf gibt sämtliche Dateien auf dfO, 
welche mit »d« oder »D« beginnen sowie die 
dazugehörigen Verzeichnisnamen aus. 

FIND ">prt: dfO:" d#? 

gibt dieselben Dateien auf den Drucker aus. 
Wer sich intensiver mit »all« beschäftigt, 
wird sicher noch viele andere nützliche Ver¬ 
wendungsmöglichkeiten finden. Ausgespro¬ 
chen nützlich ist dabei die LFORMAT-Funk- 
tion des LIST-Befehls. Bsp.: 
all dfO: "list >T:qwe #? LF0RMAT='protect 
%a -d'" "execute T:qwe" 
delete T:qwe 

Die beiden Zeilen schützen alle Dateien 
auf DFO: davor gelöscht zu werden. 

that's »all« Daniel Görtz/ub 


1: /* -geschrieben unter Kickstart VI.3 
2: -läuft auch unter Kickstart V2.0 

3: -übersetzt mit Aztec C-Compiler V5.0 

4: Aufruf: cc all -pa -wd -wp -wr -wu 

5: ln all c.lib 

6: -läßt sich auch mit DICE übersetzen */ 

7: #include <string.h> 

8: #include <stdlib.h> 

9: Dinclude <functions.h> 

10: #include <libraries/dos.h> 

11: #include <libraries/dosextens.h> 

12: #define PUT(s) WriteUBPTR) OutputFile, s 
, (long) strlen(s)) 

13: #define BREAK ((SetSignal(OL, OL) & 4096 
L) == 4096L) 

14: #define HI_0N "\033[33m" 

15: #define HI.OFF "\033[0m" 

16: enum Fehler { Kein_Fehler, Speicher_Fehler 
, Disk_Fehler, Befehl_Fehler, Falscher_Auf 
ruf, Abbruch }; 

17: enum wann { Anfang, Ende }; 

18: void Aufruf(char ‘FName, struct FileHandle 
‘OutputFile) 

19: { PÜT("Aufruf: ’HI.ON); PUT(FName); 

20: PUT(HI.OFF" [-A] [-E] Verzeichnis Befeh 

11 [Befehl2 Befehl3 ...]\n"); 

21: PUT("\t "); PUT(FName); 

22: PUT(* durchläuft rekursiv einen Verzeich 

nisbaum und führt\n"); 

23: PUT("\t dabei die angegebene Befehlsfolg 

e aus.\n"); 

24: PUT("\t Verzeichnis Name des Verzeich 

nisses, welches\n"); 

25: PUT(*\t den Verzeichnisba 

um festlegt.\n"); 

26: PUT("\t \"\" steht fuer d 

as aktuelle Verzeichnis.\n"); 

27: PUT{"\t Befehll DOS-Befehle, die 

in den Verzeichnissen des\n"); 

28: PUT(*\t [Befehl2 ...] Verzeichnisbaumes 

ausgeführt werden sollen.\n"); 

29: PUT("\t Mindestens ein Be 

fehl muß angegeben werden.\n"); 

30: PUT("\t Da unter AMIGA-DO 

S keine Anführungszeichen^"); 

31: PUT(*\t ‘ übergeben werden 

können, muß man stattdessen\n"); 

32: PUT("\t ein Hochkomma (Al 

t+Ä) übergeben.\n *); 

33: PUT("\t \’\' steht für da 

s Hochkomma selber.\n"); 

34: PUT("\t [-A] [-E] Über diese Option 

alen Parameter wird festgelegt in\n"); 

35: PUT(“\t welcher Reihenfol 

ge die Verzeichnisse abgearbeitet\n"); 

36: PUT("\t werden. Wird -E g 

ewählt, so wird mit dem Ende des\n"); 

37: PUT("\t Verzeichnisbaumes 

begonnen; bei -A mit dem Anfang.\n"); 

38: PUT("\t -A ist voreingest 

eilt, muß also nicht explizit\n"); 

39: PUT("\t angegeben werden. 

\n\n"); 

40: PUT("\t Tritt ein Fehler 

auf oder wird durch CTR-C abge-\n"); 

41: PUT("\t brochen, liefert 

"); PUT(FName); 

42: PUTC den Fehlere 

ode 10.\n\n’); 

43: PUT(HI_ON"\t (c)M&T - ges 

chrieben von Daniel Görtz\n\n"HI_OFF); 

44: } 

45: void Hochkomma_beruecksichtigen(char “Bef 
ehle) 

46: (char ‘Befehl; 

47: while<‘Befehle) 

48: { Befehl = ‘Befehle; 

49: while(‘Befehl) 

50: { if(‘Befehl == ’\" && *(Befehl+l) == 

*\") 

51: { char ‘Dummy = Befehl; 

52: while(‘Befehl = *(Befehl+l)) Befeh 

1 ++; 

53: Befehl = Dummy; 

54: } 

55: eise 

56: if(‘Befehl == *\") ‘Befehl = '\*' 

57: ’ Befehl++; 

58: } 

59: Befehle++; 

60: ) 

61: } 

62: enum Fehler Befehle_ausfuehren (char “Befe 
hie, struct FileHandle ‘OutputFile) 

63: { while(‘Befehle) 

64: if(!(Execute(*Befehle++, NULL, OutputF 


ile))) 

65: retum Befehl_Fehler; 

66 

retum Kein Fehler; 

67 

) 

68: enum Fehler durchlaufe_Verzeichnis(char *V 

erzeichnis, char “Befehle, struct FileHan 
die ‘OutputFile, enum wann Zeitpunkt) 

69: { enum Fehler Error = Kein Fehler; 

70: struct FileLock ‘lock = NULL, ‘oldlock = 

71 

NULL; 

struct FilelnfoBlock ‘InfoBlock = NULL; 

72 

if(!(lock = (struct FileLock *) Lock(Ver 

73 

zeichnis, ACCESS_READ))) 

{ Error = Disk_Fehler; goto FunkEnde; 

\ 

74 

i 

oldlock = (struct FileLock *) CurrentDir 

75 

((struct FileLock *) lock); 
if(i(InfoBlock = (struct FilelnfoBlock * 

76 

/ 

malloc(sizeof(struct FilelnfoBlock) 

))) 

{ Error = Speicher_Fehler; goto FunkE 

77 

nde; ) 

78: if(!(Examine((BPTR) lock, (BPTR) InfoBlo 

79 

ck))) 

{ Error = Disk_Fehler; goto FunkEnde; 

; 

80: if(Zeitpunkt == Anfang) 

81: Error = Befehle_ausfuehren(Befehle, Ou 

tputFi'le); 

82: while(ExNext((BPTR) lock, (BPTR) InfoBlo 

83 

ck) && Error == Kein.Fehler) 

{ if(InfoBlock->fib_DirEntryType >= 0) 

84 

durchlaufe.Verzeichnis(InfoBlock->fi 

85 

b_FileName, Befehle, OutputFile, Zeitpunkt 
); 

if(BREAK) { Error = Abbruch; goto Funk 

86 

Ende; } 

} 

87 

if(Zeitpunkt == Ende) 

88 

Error = Befehle ausfuehrenlBefehle, Ou 

89 

tputFile); 

FunkEnde: 

90 

if(lock) 

91 

{ UnLock((BPTR) lock); 

92 

CurrentDir(oldlock); 

93 

} 

94 

if(InfoBlock) free(InfoBlock); 

95 

retum Error; 

96 

} 

97 

void main(int arge, char “argv) 

98 

{ struct FileHandle ‘OutputFile; 

99 

enum wann Zeitpunkt - Anfang; 

100 

enum Fehler Error; 

101 

OutputFile = (struct FileHandle *) Outpu 

102 

t(); 

if(argc >= 3) 

103 

{ Hochkomma_beruecksichtigen(argv); 

104 

if(!strcmp(argv[l], "-e") II !strcmp(a 

rgv[1), "-E")) 

105: Zeitpunkt = Ende; 

106: if(!strcmp(argv[l], "-a") II !strcnp(a 

107 

rgv[l], *-A") II Zeitpunkt == Ende) 

Error = durchlaufe_Verzeichnis(argv[ 

108 

2], argv+3, OutputFile, Zeitpunkt); 

• eise 

109: Error = durchlaufe_Verzeichnis(argv[ 

110 

1], argv+2, OutputFile, Zeitpunkt); 

) 

111 

eise 

112 

Error = Falscher Aufruf; 

113 

switch(Error) 

114 

{ case Speicher_Fehler: 

115 

PUT("Fehler wegen Speichermangels au 

116 

fgetreten !\n"); 
exit(10); 

117 

case Disk Fehler: 

118 

PUT("Verzeichnis nicht vorhanden ode 

119 

r zerstört !\n"); 
exit(10); 

120 

case Befehl_Fehler: 

121 

PUT("Befehl konnte nicht ordnungsgem 

122 

äß ausgeführt werden I\n*); 
exit(10); 

123 

case Falscher Aufruf: 

124 

Aufruf(argv[0], OutputFile); 

125 

exit(10); 

126 

case Abbruch: 

127 

PUT("*“ BREAK\n"); 

128 

exit(10); 

129 

case Kein Fehler: 

130 

exit(0); 

131 

) 

132 

} © 1993 M&T 

»Alle«: Weitet DOS-Befehle auf ganze 

Verzeichnisse aus 


hhi 
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TIPS & TRICKS 


RfUJIfHJ 

Computer Systeme 


AMIGA 4000 


A4000-40 

A4000-120 


AMIGA 500/600 


A600-HD 40 MB 999.- 

A601 1 MB RAM Expansion 125,- 
2. Laufwerk extern 129,- 

Orgaton 508 85 MB Quantum755,- 


i 


AMIGA 2000 


A2000 D 

1045,- 

A2320 Flickerfixer 

425,- 

A2630 Turbokarte 2 MB 

1195,- 

A2386 SX-20-Karte 

990,- 

MasterCard 2 MB RAM-Karte 250,- 

Masoboshi AT/SCSI Cont. 

385,- 

Nexus SCSI Cont./RAM opt. 

345,- 

Nexus SCSI Cont. 

85 MB Quantum 

755,- 

2. Laufwerk intern 

115,- 

AMIGA 3000 

A3000-25-50 

2795,- 

A3000-25-100 

2995,- 

Monitore 

A1084S 

475,- 

Hitachi 14 MVX 

975,- 

14" SAMPO Multisync 

835,- 


Drucker 


HP Deskjet 500 
HP Deskjet 500C 


Multimedia 


Video Echtzeit-Digitizer 
Genlock 


Weitere Produkte auf Anfrage. 
Irrtümer und Druckfehler 
Vorbehalten. 


2900 Oldenburg 
Hauptstraße 107 
Telefon 0441/504770 
Fax 503640 

2833 Harpstedt 
Bassumerstraße 19 
Telefon 04244/1877 
Fax 1731 


Gleitpunktzahlen 

Genauigkeit zählt 


Das Betriebssystem des Amiga 
unterstützt eine Reihe Datenfor¬ 
mate unterschiedlicher Genauig¬ 
keit. Jedes bietet eine Reihe von 
Vor- und Nachteilen: Entweder 
man will es ganz genau, oder man 
möchte besonders schnell sein. 

von Roger Fishlin 

D er bekannteste numerische Datentyp 
der Klasse der Festpunktzahlen ist 
»Integer«, der nur ganze Zahlen spei¬ 
chert. Um Nachpunktstellen zu verarbeiten, 
muß ein anderer Datentyp mit Gleitpunktdar¬ 
stellung gewählt werden. In PASCAL gibt es 
für reelle Zahlen den Typ REAL, analog in 
der Programmiersprache C den Typ FLOAT. 
Der Name FLOAT leitet sich aus der engli¬ 
schen Bezeichnung für Gleitpunktdarstellung 
ab: »Floating Point«. Bei sehr kleinen oder 
großen Beträgen ist die Exponentialdarstel- 
lung üblich: der Ausdruck »1.2E-20« bedeu- 
tetz.B. »1.2*10 20 «. 

Die aktuelle Betriebssystemversion Kick¬ 
start 2.0 bietet dem Programmierer insgesamt 
drei Gleitpunktdarstellungen an: 

- Fast Floating Point (FFP) 

- Single Precision (IEEE-SP) 

- Double Precision (IEEE-DP) 

»Single Precision« wurde erst mit Kick¬ 
start 2.0 eingeführt, »Fast Floating Point« 
und »Double Precision« existieren bereits 
unter Kickstart 1.2. Die beiden IEEE-For- 
mate wurden rechnerübergreifend als Stan¬ 
dardimplementationen des »Institute for 
Electrical and Electronic Engineers«, kurz 
»IEEE«, definiert. 

Das FFP-Format unterstützt der Amiga 
durch die beiden Libraries »mathffp.library« 
und »mathtrans.library«. Die erste Bibliothek 
ist ROM- und die zweite disk-resident, muß 
also bei Bedarf aus dem Verzeichnis »LIBS:« 
geladen werden. Die »mathffp.library« ent¬ 
hält Grundoperationen wie Addition und 
Multiplikation; transzendente Funktionen 
(z.B. Exponentionalfunktion und trigonome¬ 
trische Funktionen wie Sinus) findet man in 
der »mathtrans.library«. Die maximale Ge¬ 
nauigkeit beträgt im FFP-Format sieben 
Dezimalstellen. Außer der Null können Zah¬ 
len im Bereich von +/-10' 20 bis +/-10 18 darge¬ 
stellt werden. Auf den ersten Blick mag es 
nicht einleuchtend sein, weshalb kein zusam¬ 
menhängendes Intervall möglich ist. Der 
Grund: Die Darstellung der Zahlen im Inter¬ 
vall [0,10 A -20] und dem analogen Bereich 
der negativen Zahlen würde mehr Bits als in 
der Norm vorgesehen benötigen. 


Intern entspricht eine FFP-Zahl 32 Bit (ein 
Longword), arithmetische Operationen dür¬ 
fen allerdings nur mittels Library-Routinen 
ausgeführt werden. Assembler-Programmie¬ 
rer können zum Beispiel zwei FFP-Zahlen 
nicht durch den Assembler-Befehl »ADD« 
addieren. Die Linkerbibliothek »amiga.lib« 
enthält u.a. zwei Routinen für die Umwand¬ 
lungen eines ASCII-Strings in eine FFP-Zahl 
(»afp«) und umgekehrt (»fpa«). Nähere 
Informationen entnehmen Sie der offiziellen 
Dokumentation ([2]). Assembler-Program¬ 
mierer müssen die Parameter in umgekehrter 
Reihenfolge auf dem Stack ablegen, »JSR 
_afp« bzw. »JSR _fpa« ausführen und den 
Stack-Pointer wieder korrigieren. Vergessen 
Sie nicht, das Objectfile anschließend mit 
dem »amiga.lib« zu linken. 

Zwar ist auf einem Amiga mit 68000er 
CPU die Verarbeitung von Zahlen in FFP- 
Darstellung schneller als die nach der IEEE- 
Norm, aber bei einem mathematischen 
Coprozessor (MC68881/2) ändert sich die 
Relation. Der Grund: Die FFP-Libraries kön¬ 
nen nicht von Coprozessoren profitieren, da 
er im Gegensatz zur IEEE-Norm das FFP- 
Format nicht beherrscht. Alle IEEE-Libraries 
arbeiten hingegen (seit Kickstart 1.3 automa¬ 
tisch) mit dem Coprozessor. Fehlt er, müssen 
die Bibliotheken dessen Befehle mit Hilfe der 
CPU zeitaufwendig emulieren. 

Ähnlich der FFP-Libraries sind die IEEE- 
Bibliotheken in arithmetische Grundoperatio¬ 
nen und transzendente Funktionen unterteilt: 
»mathieeesingbas.library«, »mathieeesing- 
trans.library«, »mathieeedoubbas.library«, 
»athieeedoubtrans.library«. Bis auf die Li¬ 
brary mit den Basisoperationen für einfache 
Genauigkeit sind momentan die Bibliotheken 
disk-resident. 

Bei einfacher Genauigkeit (»Single Preci¬ 
sion«) werden Gleitpunktzahlen ebenfalls in 
32 Bit abgelegt. Jedoch unterscheidet sich der 
Aufbau vom FFP-Format, weshalb man die 
Zahlendarstellungen nicht direkt austauschen 
darf. Dargestellt werden können neben der 
Null Werte von +/- 10 A -37 bis +/- 10 A 38. 
Arithmetische Operationen mit einfacher 
Genauigkeit erzielen bestenfalls auf sieben 
Dezimalstellen das korrekte Resultat. 

In 64 Bit, also zwei Longwords, wird die 
Gleitpunktzahl bei doppelter Genauigkeit im 
IEEE-Format kodiert. Neben der Null können 
Zahlen im Bereich +/- IO’ 308 bis +/- 10 307 dar- 
gestellt werden, ein Rechenergebnis ist höch¬ 
stens auf 16 Dezimalstellen exakt. ub 

Literatur: 

111 Commodore-Amiga. Inc.: "AMIGA ROM Kemal Reference 
Manual: Libraries". 1992. ihird Edition. Addison-Wesley 
Publishing Company. Inc.. ISBN 0-201-56774-1 
[2] Commodore-Amiga. Inc.: "AMIGA ROM Kernal Reference 
Manual: Includes And Aulodocs". 1992, third Edition. Addison- 
Wesley Publishing Company. Inc.. ISBN 0-201-56773-3 
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ARexx-Utilities 

Königliche Hilfe 


An Stelle von AmigaBASIC wer¬ 
den die neuen Amigas mit der 
Interpretersprache ARexx ausge¬ 
liefert. Was leistet diese Sprache? 
Was kann man mit Ihr anfangen? 
Hier ein paar Beispiele, die zei¬ 
gen, daß ARexx Ihnen mit Ihrem 
Amiga viel abnehmen kann. 

von Ilse u. Rudolf Wolf 

A Rexx wird meist nur zum Steuern oder 
als Ergänzung anderer Programme 
verwendet. Dabei wird von vielen 
häufig übersehen, daß diese Sprache - 
obwohl als Interpretersprache langsam - 
mehr Möglichkeiten bietet als AmigaDOS- 
Scripts und daher auch für Batch-Dateien und 
eigenständige Programme verwendet werden 
kann. Wenn zusätzlich Bibliotheken aus dem 
PD-Bereich eingebunden werden (z.B. die 
»rexxarp.librar« und »screenshare.library«), 
kann man sogar fast alle Möglichkeiten des 
Amiga-Betriebssystems nutzen. Für kurze 
Dienstprogramme eignet sich ARexx beson¬ 
ders. Das wollen wir Ihnen anhand einiger 
ARexx-Scripts zeigen. 

Dellnfo.rexx: 

Wenn die Diskettensammlung wächst, ver¬ 
liert man bald die Übersicht, was, wo drauf 
ist. Als einfachste Möglichkeit zur Archivie¬ 
rung genügt es, das Inhaltsverzeichnis auszu¬ 
drucken und abzulegen. Leider ist so ein 
Ausdruck unübersichtlich: Erstens wegen der 
».info«-Dateien und zweitens weil zweispal¬ 
tig. Das erste ARexx-Script, das wir vorstel¬ 
len, »Dellnfo.rexx«, macht einen Directory- 
Ausdruck übersichtlicher. 

Die Ausgabe erfolgt einspaltig, wobei alle 
Dateien mit der Endung ».info« übersprun¬ 
gen werden. Das Ergebnis wird in der RAM- 
Disk als Text unter dem Namen »Dir.txt« 
abgelegt und anschließend mit MORE ange¬ 
zeigt, so daß ein Vor- und Zurückblättern im 
Inhaltsverzeichnis möglich wird. 


/* ======== Dellnfo.rexx ======== */ 

options prompt " Verzeichnis u. Option >" 
pull dirname 

befehl = "dir >ram:dummy" dirname 
say " Bitte warten ..." 

/* AmigaDOS-Befehl ausführen */ 
address COMMAND befehl 
/* Dateien öffnen */ 
open (lese, "ram:dummy\ "r") 
open(sende,"ram:Dir.txt","w") 

/* Datum und Uhrzeit holen */ 
datum=DATE();dd=left(datum,2) 
if left(dd,l)="0" then dd=right(ad,l) 

/* Ausgabestring formatieren */ 


dt = DATE("W") dd DATE CM") right(datum,4)" - 

"TIMEO 

/* Überschrift V 

writeln(sende,"Directory von" dirname) 
writeln(sende,dt) 

/* Umformatierungs-Schleife */ 
do while -eof(lese) 
zeile= readln(lese) 
y=" *;n=0 

/* Leerzeichen für ermitteln */ 
do while y=* " & n< length(zeile) 
n=n+l 

y=substr(zeile,n,l) 
end 

if n~=0 then n=n-2 
y=copies(" ",n) 

/* Zeilen-Parser */ 
parse var zeile eins zwei 
zwei=strip(zwei,*b") 
if zwei="(dir)" then do 
eins= eins II zwei 
writeln(sende,y I eins) 
end 

eise do 

if index(eins,'.info')=0 & length(eins)>0 
then writeln(sende,y II eins) 
if index(zwei,'.info')=0 & length(zwei)>0 
then writelnlsende,y II zwei) 
end 
end 

/* Geöffnete Dateien schließen */ 
call close(lese) 
call close(sende) 

/* Hilfs-Datei schließen */ 

address COMMAND 

'delete >NIL: ram:dummy' 

'echo **ec"' 

’more ram:Dir.txt' © 1993 M&T 

»Dellnfo.rexx«: gibt ein Verzeichnis aus 
wie DIR - allerdings ohne Info-Dateien 


Die Bedienung ist einfach; es braucht nur 
der Directory-Befehl eingetippt werden,z.B.: 
dfl: gibt nur das Hauptverzeichnis der 

Diskette im Laufwerk DF1 aus; 
dfl: all gibt alle Verzeichnisse der 
Diskette im Laufwerk DF1 aus; 
sys:prefs zeigt den Inhalt von »Prefs« von 
der System-Diskette; 
c: listet den Inhalt von C:. 


aList.rexx 

Für die Archivierung einer Diskette ist es 
sinnvoll, auch die Dateilängen und das 
Erstellungsdatum festzuhalten. Für ein Ver¬ 
zeichnis liefert diese Angaben der LIST- 
Befehl. Doch den Inhalt aller Verzeichnisse 
der Reihe nach mit LIST auszugeben, ist eine 
aufwendige Sache. Mit dem ARexx-Script 
»aList.rexx« ist alles wesentlich einfacher, 
denn man braucht nur das Laufwerk (z.B.: 
dfO:, dfl:, dhO: etc.) einzugeben. Alles andere 
besorgt »aList.rexx«. 

Auch hier werden alle Dateien mit der 
Endung ».info« übersprungen. Das Ergebnis 
wird in der RAM-Disk als Textdatei unter 
dem Namen »aList.txt« abgelegt. Auch hier 
erfolgt anschließend die Anzeige des Ergeb¬ 
nisses mit MORE. 


/* ========== aList.rexx ========== */ 

options prompt " Welches Laufwerk? > " 
pull drive 

say * Bitte warten..." 

/* Header speichern */ 
befehl='list >ram:dummy' drive 

'dirs quick nohead' 

address COMMAND befehl 
/* Inhalte speichern */ 

open(lese,"ramtdummy","r") /* Hilfs-Datei V 
open(sende,"ram:aList.txt",’w") 
call close(sende) /* LIST schreibt in Datei */ 
do while -eof(lese) /*.info-Datei auslassen */ 
zeile=readln(lese) 
zeile='list »ram:aList.txt' drivei 

zeile 'p -(#?.info)’ 

address COMMAND zeile 
open(leer, "ranuaList.txt", "a") 
writelnlleer,"") f* Leerzeile */ 
call close(leer) 
end 

call close(lese) 

address COMMAND 
'echo "*ec"' 

•more ranuaList.txt' /* Ausgabe */ 

'delete >NIL: ramrdummy' © 1993 M&T 

»List.rexx«: wenn Sie den Inhalt einer 
ganzen Diskette auflisten möchten 


Copy6ÖOHD.rexx 

Der Amiga600HD wird mit einer Festplatte 
und einem Diskettenlaufwerk geliefert. Das 
bedingt, daß man beim Kopieren einer Dis¬ 
kette mit nur einem Laufwerk zum Disk¬ 
jockey wird. Abhilfe schafft das ARexx- 
Script »Copy600HD.rexx«. O 


/* Copy600HD.rexx */ 

/* kopiert Disk mit A600HD in einem Durchgang 

say "" 

say " Bitte Quell-Diskette einlegen" 
options prompt " und RETURN-Taste drücken" 
pull warte 
address COMMAND 
/* Puffer anlegen */ 
if ~exists('dhO:buffer') then do 
'makedir dhO:Buffer' 
bufnam="dhO:Buffer" 
end 

empty=bufnam II"/#?" 

'delete >NIL:' empty 
target="dfO: to" bufnam "all" 

’copy' target 
Start: 

'echo "*ec"' 

say "Bitte Ziel-Diskette einlegen" 
options prompt * und RETURN-Taste drücken" 

*pull warte 

target=bufnam "to dfO: all" 

'copy' target 
'echo "*ec"' 

say ’ Diskette kopiert!" 

options prompt " Noch eine Diskette?-j/n > " 

pull jn 

if upper(jn)~="J" then do 
say " Puffer wird gelöscht!" 

'delete >NIL:' bufnam 'all* 
end 

eise do 
Signal Start 

end © 1993 M&T 

»Copy600HD.rexx«: hilft, wenn Sie mit 
dem Amiga 600 HD Diskette kopieren 
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Das Programm legt auf der Festplatte einen 
Puffer an und kopiert die Quelldiskette vom 
Laufwerk DFO: in den Puffer. Danach 
erscheint die Aufforderung, die Zieldiskette 
einzulegen, und der Kopiervorgang erfolgt in 
umgekehrter Richtung. Ist er beendet, fragt 
der Amiga, ob der Puffer auf eine weitere 
Diskette kopiert werden soll - eine zeitspa¬ 
rende Methode für Mehrfachkopien. 

DelRemRX.rexx und DelRemBas.rexx 

Ein Listing sollte mit Kommentaren versehen 
werden, weil es dadurch verständlicher wird. 
In Interpreter-Sprachen verlangsamt das 
allerdings die Ablaufgeschw'indigkeit. Es ist 
daher sinnvoll, eine kommentarlose Arbeits¬ 
kopie zu verwenden. 

»DelRemRX.rexx« entfernt aus einem 
ARexx-Script alle Kommentare, wobei die 
erste Zeile - die ja in ARexx eine Kommen¬ 
tarzeile sein muß - erhalten bleibt. 


/* ======= DelRem.rexx ======= */ 

say • Entfernt Kommentare aus ARexx-Programmen" 
say "" 

options prompt " Quell-Datei: " 
pull source 

options prompt " Ziel-Datei : " 
pull target 
open(lese,source," r") 
open(sende,target,"w") 

/* ARexx-Kennung uebemehmen */ 
zeile= readln(lese) 
writeln(sende,zeile) 
do while ~eof(lese) 
zeile= readln(lese) 
xl=index(zeile, V*",l) 
yl=index(zeile,•*/■) 
select 

when zeile=""then NOP 
when xl~=0 

then zeile=delstr(zeile,xl) 
when yl~=0 & xl=0 
then zeile=delstr(zeile,1) 
otherwise NOP 
end 

zeile=trim(zeile) 
if zeile -=" 
then writeln(sende,zeile) 
end 


call close(lese) 
call close(sende) 

say "READY!" © 1993 M&T 

»DelRem.Rexx«: entfernt Kommentare 
aus einem ARexx-Script 


Analog dazu entfernt das Programm »Del- 
RemBAS.rexx« alle Kommentare aus einem 
AmigaBASIC-Listing, wobei wieder die erste 
Zeile erhalten bleibt. 

Die Bedienerführung beider Dienstpro¬ 
gramme ist selbsterklärend. 


/* ======= DelRem.rexx ======= */ 

say " Entfernt Kommentare aus AmigaBASIC- 

Programm" 

say "" 

options prompt " Quell-Datei: * 
pull source 

options prompt 0 Ziel-Datei : " 

pull target 

open(lese,source,"r") 

open(sende,target,"w") 

/* 1.Zeile übernehmen */ 
zeile= readln(lese) 
writeln(sende,zeile) 

/* Kommentare entfernen */ 
do while -eof(lese) 
zeile= readln(lese) 
xl=index(zeile,"REM",1) 
x2=index(zeile,"'") 
x3=index(zeile,":REM",3) 
select 

when zeile=""then NOP 
when x3~=0 

then zeile=delstr(zeile,x3) 
when xl~=0 

then zeile=delstr(zeile,xl) 
when x2~=0 

then zeile=delstr(zeile,x2) 
otherwise NOP 
end 

zeile=trim(zeile) 
if zeile ~=" 
then writeln(sende,zeile) 
end 

call close(lese) 
call close(sende) 
say "READY!" 

© 1993 M&T 

»DelRemBAS.Rexx«: entfernt alle Kom¬ 
mentare aus einem BASIC-Listing 


Guten START mit 
ARexx 

Damit Sie die ARexx-Scripts auch von der 
Workbench aus starten können, müssen Sie 
fünf Project-Icons bereitstellen (z.B. mit dem 
IconEdit). Diese erhalten jeweils den Namen 
des ARexx-Scripts. In jedes Icon wird in das 
»Default Tool«-Feld eingetragen: 

SYS:rexxc/RX 

Die »Tool Types« unterstützen als Argu¬ 
mente CONSOLE und CMD, wobei CON- 
SOLE für ein Fenster steht. Wenn Sie dort 
CONSOLE=CON:0/ö/639/255/ARexx Output 
eintragen, erhalten Sie ein bildschirmfüllen¬ 
des Fenster. 

Der Vollständigkeit halber: CMD ist das 
»Tool Types«-Schlüsselwort für einen Kom¬ 
mandostring. Wird dort nichts eingetragen, 
versucht der RX-Befehl, die zum Icon 
gehörende Datei als ARexx-Programm aus¬ 
zuführen. Für die vorgestellten Programme 
ist ein CMD-Eintrag nicht erforderlich. CMD 
wird jedoch gebraucht, wenn einem ARexx- 
Script Argumente mitgegeben werden müs¬ 
sen oder wenn das Project-Icon nur als Star¬ 
ter für ein ARexx-Programm dient. Ein ana¬ 
loges Beispiel ist das Shell-Icon. 

Abschließend noch ein Hinweis: Für den 
Workbench-Start muß der ARexx-Server 
bereits aktiviert sein. Wenn nicht, gibt es fol¬ 
gende Fehlermeldung: 

rexxmast: unknown coimnand 
rexxmast failed retumcode 10 
ARexx Server not active 

Da nun alles klappen dürfte, bleibt nur 
noch, Ihnen viel Spass mit ARexx zu wün¬ 
schen. ub 

Literaturnachweis: 

Eric Giguere: AMIGA Programmeris Guide to ARexx 
Commodore-Amiga.Inc..West Chester. Pennsylvania 
Commodore: Handbuch zur Systemsoftware 2.0 
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APIG-Library (Fish 634) 


Der König ist tot - Es lebe 

APIG 


Mit der im vorigen Artikel vorge¬ 
stellten Interpretersprache ARexx 
erhebt sich vor allem eine Frage: 
Kann ARexx auch AmigaBASIC 
ersetzen? Die Antwort lautet ein¬ 
deutig »ja« - vor allem, wenn 
zusätzlich eine leistungsfähige 
externe Funktionsbibliothek wie 
APIG zur Verfügung steht. 

Ilse u. Rudolf Wolf 

W ie auf Seite 55 erwähnt werden alle 
Amiga-Modelle ab Betriebssystem¬ 
version (OS) 2.0 nicht mehr mit 
AmigaBASIC ausgeliefert. Dafür ist ARexx 
ein fester Bestandteil des Amiga-Betriebssy- 
stems. Was diese Sprache kann, haben wir im 
genannten Artikel beleuchtet. Doch ARexx 
leistet noch einiges mehr als Skriptsprachen. 

Grundsätzlich ist ARexx eine Kommando¬ 
sprache, mit der es möglich ist, Programme 
fernzusteuern. In der Literatur findet man 
daher fast nur solche Anwendungen. 

ARexx kann aber auch als die logische 
Weiterentwicklung des CLI betrachtet wer¬ 
den, denn im Gegensatz zum CLI besitzt es 
einen komfortablen Befehlssatz. Dazu 
kommt, daß dieser mit externen Funktionsbi¬ 
bliotheken fast unbegrenzt erweiterbar ist. 
Aus dem Fish-Aquarium kann man sich eine 
Reihe brauchbarer Funktionsbibliotheken 
herausangeln (siehe Tabelle). 


Fish- 

Disk 

Name 

Funktion 

227 

RexxArpLib 

Zugriff auf ARP-Funktionen 
ermöglichen. 

227 

RexxMathUb 

ARexx um trigonometrische 
Funktionen erweitern. 

308 

ScreemhareLib 

von RexxArpLib benötigt 

459 

RxGen 

Zugriff auf Amiga - 
Bibliotheken ermöglichen 

463 

Rexxlntuition 

Zugriff auf diverse Intuition - 
Funktionen ermöglichen. 

629 

RexxRMF 

Datenbank in ARexx 
erstellen (AVL trees) 

634 

APIG 

ermöglicht Zugriff auf Exec- 



Asl-, Graphics-, Intuition-, 
Layers-, Utility- und 

Gadtools- Funktionen. 

682 

RexxHostLib 

Bibliothek mit Funktionen 
ßr eine ARexx-Schnittstelle 


Tabelle: Im PD-Pool finden Sie viele 
Bibliotheken, um ARexx zu erweitern 


Damit ist ARexx nicht nur als eine Batch- 
Sprache zur automatisierten Steuerung oder 
eine Makro-Sprache zur Steuerung eines 
Anwenderprogrammes sondern als univer¬ 
selle Programmiersprache einsetzbar und 
übertrifft AmigaBASIC in vielen Belangen. 

Die »apig.Iibrary« 

Der beste Fang aus dem Fish-Aquarium 
dürfte derzeit die APIG (A Programmers 
Intuition & Graphics Library) auf der Fish 
634 sein, denn mit der »apig.Iibrary« ist der 
Zugriff auf 288 Funktionen aus den Amiga- 
OS2.0-Bibliotheken (Asl, Exec, Gadtools, 
Graphics, Intuition, Layers und Utility) mög¬ 
lich. Zusätzlich enthält die Bibliothek über 
600 Konstanten und Flags, wie sie in den 
Include-Files definiert sind. Kein Wunder, 
daß die »apig.Iibrary« 61220 Byte lang ist 
und daß das auf Diskette befindliche, ausge¬ 
druckte Manual rund 50 Seiten umfaßt. 


1: /* =========== Flush.rexx ===========*/ 

2: say 'Oa'x "ARexx-Resources-Liste:* 

3: say "" show(’l') 

4: if(show('1','rexxsupport.library’)) then do 
5: say " REMLIB -> rexxsupport.library" 

6: call remlib('rexxsupport.library') 

7: end 

8: if(show('1','apig.Iibrary')) then do 
9: say " REMLIB -> apig.Iibrary" 

10: call remlibCapig.Iibrary') 

11: end 

12: if (show( '1' .-'rexxmathlib.library')) then do 
13: say "REMLIB -> rexxmathlib.library" 

14: call remlibC rexxmathlib. library') 

15: end 

16: address COMMAND ’avail >NIL: flush' 

17: say 'Oa'x "Neue ARexx-Resources-Liste:" 

18: say "" show('l') 'Oa’x 

19: say " Ferner wurden auch alle ungenutzen" 

20: say ■ LIBS u. DEVS aus dem Speicher entfern 
t" 

21: options prompt * RETURN-Taste beendet.." 

22: pull holdit © 1993 M&T 

»Flush.rexx«: Ein erstes Beispiel für den 
Einsatz von APIG 


Das kurze Listing »Flush.rexx« zeigt, wie 
ein Programm aussieht, das mit Hilfe der 
»apig.Iibrary« auf Systemfunktionen zurück¬ 
greift. In diesem Fall löscht das Programm 
ungenutzte Libraries und Devices aus dem 
Speicher. 

In den meisten Fällen konvertiert die 
»apig.Iibrary« die ARexx-Stringparameter in 
ein Format, das die Amiga-Bibliotheksfunk- 
tionen erwarten. C-Programmierer werden 
ihre Freude daran haben, denn die Portierung 
ermöglicht ein flexibles und funktionelles 
Programmieren ähnlich wie in C. 


Folgende Strukturen werden unterstützt: 
Menu, Menuitem, Subitem, Requesters, Boo- 
lean, String- und Proportional-Gadgets, Bor- 
ders, IntuiText, 16-Bit-Arrays, Layers und 
IFF (via »iff.library« von Christian Weber). 
Allen die mit Intuition/Graphics-Funktionen 
und Strukturen nicht vertraut sind, empfiehlt 
der Programmierer Ronnie E. Kelly daher 
das Studium der Includes & Autodocs. 

Schauen wir uns ein zweites Beispiel an: 
»AslFilel.rexx« demonstriert, wie man einen 
ASL-Requester von ARexx aus aufruft. 


1: /* ========== AslFilel.rexx ========== 

2: Einfacher MultiFileRequester mit 

3: ALLOCFILEREQUEST() u. REQUESTFILE() */ 

4: /* Externe Bibliotheken einbinden */ 

5: if(~show('l','rexxsupport.library’)) 

6: then call addlib('rexxsupport.library',0,-30,0) 
7: if(~show{'1','apig.Iibrary')) 

8: then call addlib('apig.Iibrary',0,-30,0) 

9: /* Requester-Struktur anlegen */ 

10: freq = ALLOCFILEREQUEST() 

11: /* Parameter für REQUESTFILE V 

12: multi = 1 /* Mehrfachauswahl möglich */ 

13: save = 0 

14: hail = "MultiFileRequester" 

15: dir = "RAM:" /* voreingest. Verzeichnis */ 

16: file = "" /* voreingest. Filename */ 

17: pat =1 /* Wenn pat > 0 :Pattern-Gadget */ 
18: nofile = 0 /* nofile > 0: nur Verzeichnisse*/ 
19: win = null() /* Zeiger auf Parentwindow */ 

20: x =0 /* linke obere Ecke */ 

21: y =0 

22: wid =500 /* Requester-Breite */ 

23: hgt = 190 /* Requester-Höhe */ 

24: sep = '0a2Q'x /* Separator Mehrfachauswahl */ 
25: /* Requester aufrufen */ 

26: filename = REQUESTFILE(freq,multi,save,hail,d 
ir,file,pat,nofile,win,x,y,wid,hgt,sep) 

27: /* Ergebnis auswerten */ 

28: if filename = nullO 

29: then say "Cancel angeklickt!" 

30: eise do 

31: say " Angeklickt wurde:" 'Oa'x 

32: say ’" filename 

33: end 

34: /* Aufräumen */ 

35: call FREEFILEREQUEST(freq) 

36: /* call remlibC rexxsupport. library’) 

37: call remlib('apig.Iibrary') 

38: address COMMAND 'avail >NIL: flush' */ 

© 1993 M&T 

»AslFilel.rexx«: ASL-Requester mit der 
»apig.Iibrary« aus ARexx aufrufen 


Wie alle Bibliotheken gehört die 
»apig.Iibrary« ins LIBS-Verzeichnis. Falls 
IFF-Funktionen verwendet werden, auch die 
»iff.library« (befindet sich ebenfalls auf der 
Fish 634); und wenn trigonometrische Funk¬ 
tionen gebraucht werden, auch die »rexx- 
math.library« von der Fish-Disk 227. 

Um für alle Fälle gerüstet zu sein und 
damit Sie möglichst viele unterschiedliche 
Funktionen in Ihren ARexx-Programmen 
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nutzen können, sollten in LIBS: folgende 
Bibliotheken vorhanden sein: 

- apig.library Fish 634 

- iff.library Fish 634 

- rexxmathlib.library Fish 227 

- rexxsupport.library 

- rexxsyslib.library 

Startvorbereitungen 

Bevor man APIG-Funktionen aufrufen 
kann, muß die »apig.library« in die ARexx- 
intemen Bibliothekenliste aufgenommen 
werden. Kelly macht das in seinen Pro¬ 
grammbeispielen mit 
call addlib('apig.1ibrary',0,-30,0) 
oder mit: 

x = addlib('apig.library',0,-30,0) 

Er setzt dabei stillschweigend voraus, daß 
die »rexxsupport. library« bereits geladen 
wurde. Ist das nicht der Fall, brechen viele 
seiner Beispiele mit einer Fehlermeldung ab, 
weil sie Funktionen aus dieser Bibliothek 
enthalten. Wir empfehlen daher, den ADD- 
LIB-Aufruf durch die folgende Sequenz zu 
ersetzen: 

if(~show('1','rexxsupport.library')) 
then call addlib('rexxsupport.library', 

0/-30,0) 

if(~show('l','apig.library')) 
then call addlib('apig.library',0,-30,0) 
Hier wird abgefragt, ob die Bibliotheken in 
die Liste eingebunden sind. Wenn nicht, wer¬ 
den sie in den Speicher geladen und in die 
Liste aufgenommen. 

Es gehört zu einem sauberen Programmier¬ 
stil, die externen Bibliotheken am Program¬ 
mende wieder aus der Liste zu entfernen. Die 
folgenden beiden Zeilen erledigen das: 
cal1 remlib('rexxsupport.library') 
call reml ib('apig.1ibrary') 

Damit sind die Libraries aus der ARexx- 
Liste entfernt, bleiben aber im RAM. Wenn 
Speicherknappheit herrscht, kann man den 
belegten Speicher mit dieser Zeile freigeben: 
address COMMAND 'avail >NIL: flush' 

Kelly verwendet in vielen Beispielen als 
Warte-Befehl das Schlüsselwort »wait« (z.B.: 
wait 5 secs). ARexx kennt das nicht und 
interpretiert das natürlich nicht als Befehl. In 
den Beispielen müssen daher alle Wait-Klau- 
seln ersetzt werden. Beispiel: 
wait 5 secs 
durch 

address COMMAND 'wait 5 secs' 

Wenn die »rexxsupport.library« geladen 
ist, geht's kürzer mit: 
call delay(250) 

Weil DELAY als Argument die Ticks/sek 
verlangt, muß für 5 Sekunden der Wert 250 
eingesetzt werden. 

Diese Hinweise sollten Ihnen helfen, Ent¬ 
täuschungen mit dieser großartigen Biblio¬ 
thek zu vermeiden. 

Anwendungsbeispiele 

Wir haben für Sie einige Anwendungsbei¬ 
spiele programmiert. Zum einen das Listing 
»Aerea.rexx«, das die Area-Funktionen der 
«graphics.library« nutzt, und »iff.rexx«, mit 


dem Sie über ARexx mit der »apig«- und der 
»iff.library« IFF-Dateien laden können. 

Damit Sie die Listings nicht abtippen müs¬ 
sen, sind sie auch auf der Begleitdiskette ent¬ 
halten (siehe Seite 114). Zusätzlich finden 
Sie auf der Diskette noch einige weitere Bei¬ 
spiele, um ASL-Requester aufzurufen, Fonts 
einzustellen usw. 

Alle Listings sind reichlich kommentiert. 
Damit Sie sich besser zurechtfinden, folgt 
eine ausführliche Beschreibung der Parame¬ 
terübergabe an die Funktionen OPEN- 
SCREEN, OPENWINDOW und PITEXT, 
die in den meisten Listings Vorkommen: 

OPENSCREEN(left,top,width,height,depth, 
dpen,bpen,vmodes,type,title) 

Diese Funktion öffnet einen Custom- 
Screen. Jeder Aufruf erzeugt einen Prozeß 
mit Namen »apig.screen.N«. N ist eine 
sequentielle Nummer zur Identifikation, die 
automatisch vergeben wird. Der Port kann 
mit dem Prozeßnamen angesprochen werden. 
Derzeit schließt aber jede Message den 
Screen. Die Bedeutung der Parameter für 
OPENSCREEN ist folgende: 
left - x-Position der linken oberen Ecke 
top - y-Position der linken oberen Ecke 
width - Breite 
height - Höhe 

depth - Tiefe (Anz. d. Bitplanes) 

dpen - Vordergrundfarbe 

bpen - Hintergrundfarbe 

vmodes - Darstellungsmodus: HIRES etc. 

type - Typ: CUSTOMSCREEN, 

WBENCHSCREEN etc. 
title - Titel (String) 

Rückgabewert: Zeiger auf den Screen als 

Rexx-Hexstring oder ein Null- 
Hexstring ('0000 0000'x), 
wenn OPEN mißlungen ist. 

Die Parameter für OPENWINDOW sind 
noch umfangreicher. Der Aufruf lautet: 
OPENWINDOW(port,left,top,wid,hgt,dpen,bpen, 
IDCMP,flags, title,scr,console, 
bitmap,chkmark,gadlist) 

Die Parameter im einzelnen: 


port 

- Name des IDCMP-Messageports, 

an 


den Nachrichten gesendet werden. 

left 

- x-Position der linken oberen Ecke 

top 

- y-Position der linken oberen 

Ecke 

wid 

- Breite 


hgt 

- Höhe 


dpen 

- Vordergrundfarbe 


bpen 

- Hintergrundfarbe 


IDCMP 

- IDCMP-Flags. Auswertung: 



dass = GETARG(msg, 0) 
code = GETARG(msg,1) 
qualifier = GETARG(msg,2) 
mousex = GETARG(msg,3) 
mousey = GETARG(msg,4) 
seconds = GETARG(msg,5) 
micros = GETARG(msg,6) 
window = GETARG(msg,7) 
iaddress = GETARG(msg,8) 
gadgetid = GETARG(msg,9) 


flags - Window-Flags 
title - Titel (String) 
scr - Zeiger auf Screen, für Workbench- 
Screen null() 

console - Parameter bestimnt, ob Fenster 

eine 'console' erhält (jeder Wert 
ungleich Null). Ermöglicht, mit 
WRITECONSOLEO-Funktion, in das 
Fenster zu schreiben, 
bitmap - Zeiger auf Bitmap, wenn Fenster 
ein Superbitmap-Window ist. 
chkmark - (Normal 0) Zeiger auf ein 
Menü-Haken-Image 

gadlist - Zeiger auf eine Gadget-Liste. 

Im Normalfall 0. 

Rückgabewert: Zeiger auf Window als Rexx- 

Hexstring oder Null-Hexstring 
('0000 0000'x), wenn OPEN 
mißlungen ist. 

Mit den Funktionen CLOSESCREEN und 
CLOSEWINDOW schließt man ein Fenster 
wieder. Die Aufrufe lauten: 

CLOSESCREEN(screen) - Schließt einen Screen 
CLOSEWINDOW(window) - Schließt ein Window 
Den Funktionen wird einfach der Zeiger 
auf die betreffenden Screen- bzw. -Fenster- 
sturktur des zu schließenden Objekts überge¬ 
ben. 

Alt letztes ist noch die Funktion PITEXT 
zu erwähnen, mit der man einen Text ausgibt. 
Der Aufruf lautet: 

PITEXT(rp,left,top,text,fp,bp,dm,font) 

Man übergibt folgende Werte: 
rp - Zeiger auf den Rastport in den 
der Text ausgegeben wird, 
left - x-Offset in Punkten im Rastport 
top - y-Offset in Punkten im Rastport 
text - Textstring 

fp - Textfärbe 

bp - Hintergrundfarbe 

dm - Drawmode (JAM1,JAM2...) 

font - Zeiger auf die Textattribut-Struk¬ 
tur des Zeichensatzes 
(von MAKETATTRO ) oder Null 

An die in unseren den Beispielen verwen¬ 
deten Funktionen OPENSCREENTAGLIST, 
OPEN WINDOWTAGLIST, ALLOCTAG- 
ITEMS werden die Parameter mit Tag-Listen 
übergeben. Deren Aufbau ist aus den Listings 
ersichtlich, speziell aus »AslFont.rexx« (auf 
der Diskette zum Heft). 

Im folgenden finden Sie nun zwei Bei¬ 
spiele für den Einsatz der »apig.library«: 

3 »LoadlFF.rexx« lädt ein Bild, das in Form 
einer IFF-Datei vorliegt; 

□ »Aerea.rexx« demonstriert den Einsatz der 
Area-Funktionen. 

Auf der Diskette zum Heft (siehe Seite 114) 
finden Sie weitere Beispiele sowie die kom¬ 
plette »apig.library« inklusive Dokumenta¬ 
tion. Testen Sie, was man alles mit der 
Bibliothek machen kann. ub 

Literaturnachweis: 

Commodore-Amiga.Inc..West Chester. Pennsylvania: 

Eric Gigu6re - AMIGA Programme^s Guide to ARexx 
Commodore: Handbuch zur Systemsoftware 2.0 
Commodore: Includes & Autodocs V39.108 

Fish-Disk 634: APIG 
Fish-Disk 227: rexxmathlib.library 


58 


Faszination Programmieren Nr. I 


1: /* ======== LoadlFF.rexx ========= */ 

2: 

3: /* Externe Bibliotheken einbinden */ 

4: if(-show('1','rexxsupport.1ibrary ’)) 

5: then call addlibl'rexxsupport.1ibrary*,0, 

-30,0) 

6: if(~show('1',’apig.library’)) 

7: then call addlib('apig.library',0,-30,0) 

8: 

9: /* Intuition-Konstanten und Flags setzen V 
10: call set_apig_globals() 

11: 

12: /* Speicher für Requesterstruktur */ 

13: freq = ALLOCFILEREQUEST() 

14: 

15: /* Sequester aufrufen */ 

16: hailing = "Bild-Datei oder Cancel anklicke 

n.." 

17: filename = REQUESTFILE(freq,hailing,,,,,, 
,20,400,220) 

18: if filename = null!) then do 
19: say ’ Cancel angeklickt!" 

20: call cleanupO 

21: exit 

22: end 

23: 

24: /* Selektierte IFF-Datei laden */ 

25: scr = 0 

26: picture = loadiff(filename) 

27: if picture = '0000 0000'x then do 
28: say " Das ist kein IFF-ILBM- File!" 

29: call cleanupO 

30: exit 

31: end 

32: width = iffwidth(picture) /* Display-Par 
ameter */ 

33: height = iffheight(picture) 

34: depth = iffdepth(picture) 

35: viewmode = iffviewmode(picture) 

36: ncolors = iffcolors(picture) 

37: colors = iffcolortab(picture) 

38: /* Screen öffnen */ 

39: scr = openscreen{0,0,width,height,depth,1 
,0,viemode,CUSTOMSCREEN,0) 

40: scrrp = getscreenrastport(scr) 

41: z = useiffcolor(picture,scr) 

42: 

43: /* Image in den Screen-Rastport kopieren */ 

44: z = bltbitmaprastport(picture,0,0,scrrp,0,0 
,width,height,c2d(’OOcO'x)) 

45: 

46: pull holdit /* Auf das Drücken der RETUR 
N-Taste warten */ 

47: call CLOSESCREEN(scr) 

48: call FREEBITMAP(picture) 

49: call cleanupO /* Aufräumen */ 

50: exit 
51: 

52: cleanup: 

53: call FREEFILEREQUEST(freq) 

54: /* 

55: call remlib('rexxsupport.1ibrary') 

56: call remlibl’apig.library') 

57: address COMMAND ’avail >NIL: flush' 

58: */ 

59: return © 1993 M&T 

»LoadlFF.rexx« Lädt ein Bild, das als 
IFF-Datei vorliegt 


1: /* ============= Aerea.rex ============= */ 

2: /* Beispiele für Area-Funktionen */ 
3: 

4: /* Externe Bibliotheken einbinden */ 

5: if(~show('1',’rexxsupport.1ibrary’)) 

6: then call addlib('rexxsupport.1ibrary',0 

,-30,0) 

7: if(~show('1','apig.library')) 

8: then call addlib('apig.library',0,-30,0) 

9: 

10: /* Intuition-Konstanten u. Flags initialis 
ieren */ 

11: call set_apig_globals0 
12: 

13: portname = "msgport" 

14: p = openport(portname) 

15: 

16: scrtitle = ‘ apig.screen’ 

17; wintitle = ’ apig.window’ 

18: winidcmp = CLOSEWINDÖW 
19: winflags = WINDOWCLOSE+WINDOWDRAG+WINDOWSI 
ZING+WINDOWDEPTH+GU4MEZEROZERO 

20 : 


21: scr = openscreen(0,0,640,512,3,2,l,LACE+HI 
RES,CUSTOMSCREEN,scrtitle) 

22: win = openwindow(portname,0,12,640,400,1, 
0,winidcmp,winflags,wintitle,scr,0,0,0) 

23: call activatewindow(win) 

24: winrastp = getwindowrastport(win) 

25: /* 4 Bytes für Füllmuster reservieren */ 
26: pat = a1locmem(4,MEMF_CLEAR) 

27: /* Füllmuster definieren */ 

28: z = export(pat,'5555 aaaa'x,4) 

29: /* Füllmuster setzen */ 

30: z = setafpt(winrastp,pat,l) 

31: /* Window-Rastport für area fills */ 

32: z = makearea(win,640,400,3000) 

33: if z = 0 then call cleanupO 
34: y=30 

35: do twice = 1 to 2 
36: if twice = 2 then do 

37: z = setopen(winrastp,1) /* OutlinePen 

setzen */ 

38: y=y+60 

39: end 
40: pen = 1 

41: /* Quadrate zeichnen *f 

42: do x = 10 to 600 by 60 

43: if pen > 7 then pen = 1 

44: z = setapen(winrastp,pen) 

45: z = areamove(winrastp,x,y) 

46: z = areadraw(winrastp,x+50,y) 

47: z = areadraw(winrastp,x+50,y+50) 

48: z = areadraw(winrastp,x,y+50) 

49: z = areadraw(winrastp,x,y) 

50: z = areaend(winrastp) 

51: pen = pen + 1 

52: end 

53: z = setopen(winrastp,0) 

54: end 
55: 

56: z = freearea(win) 

57: z = makearea(win,640,400,3000) 

58: /* Kreis */ 

59: z = export(pat,'0101 0101'x,4) 

60: z = setdrmd(winrastp,JAM2) 

61: z = setapen(winrastp,3) 

62: z = setbpen(winrastp,4) 

63: z = setopen(winrastp,1) 

64: z = setafpt(.winrastp,pat,0) 

65: z = move(winrastp,420,140) 

66: z = areacircle(winrastp,460,160,60) 

67: z = areaend(winrastp) 


68: /* Ellipse */ 

69: z = export(pat,'ffff ffff'x,4) 

70: z = setapen(winrastp,5) 

71: z = setbpen(winrastp,6) 

72: z = setopen(winrastp,4) 

11: z - setafpt(winrastp,pat,1) 

74: z = areaellipse(winrastp,420,220,60,40) 

75: z = areaend(winrastp) 

76: z = setbpen(winrastp,0) 

77: 

78: /* Bborder-Array anlegen */ 

79: /* (20 bytes, 5points * 2x * 2y) */ 

80: barray = allocmem(5*4,MEMF_CLEAR) 

81: x = setx(barray,0,0) ; y = sety(bar¬ 

ray, 0,0) 

82: x = setx(barray,1,150) ; y = sety(bar¬ 
ray, 1,0) 

83: x = setx(barray,2,150) ; y = sety(barray,2 
,100) 

84: x = setx(barray,3,0) ; y = sety(barray,3 

,100) 

85: x = setx(barray,4,0) ; y = sety(bar¬ 

ray, 4,0) 

86: 

87: borderl = makeborder(win,barray,5,40,20,1, 

0,JAM2,0) 

88: z = drawboraer(winrastp,borderl,0,220) 

89: z = pitext(winrastp,200,270,* <— FLOOD i 
n 2 Sekunden ",1,2,JAM2,0) 

90: call delay(lOO) 

91: 

92: z = setopen(winrastp,1) /* OPen wie 

Border-Ccolor */ 

93: z = flood(winrastp,0,60,250) /* Punkt in 

nerhalb der Border */ 

94: 

95: z = pitext(winrastp,200,300,"Ende in 10 Se 
künden \2,1,JAM2,0) 

96: call delay(500) 

97: z = freearea(win) /* Speicher freigeben */ 
98: cleanup: 

99: z = freemem(pat,4) 

100: z = ciosewindow(win) 

101: z = closescreen(scr) 

102: /* call remlibf'rexxsupport.1ibrary') 

103: call remlibl'apig.library') 

104: address COMMAND 'avail >NIL: flush'*/ 

© 1993 M&T 

»Aerea.rexx«: Zeichenfunktionen kann 
man auch von ARexx aus einsetzen 


IMPRESSUM 


Chefredakteur: Albert Absmeier : - verantwortlich für den redaktionellen Teil 
Stellv. Chefredakteur: Ulrich Brieden (ub) 

Textchef: Jens Maasberg 

Redaktion: Rainer Zeitler (rz) 

freie Mitarbeiter: Ilse und Rudolf Wolf 

Redaktionsaasistenz: Catharina Winter. Helga Weber 


So erreichen Sie die Redaktion: 

Tel. 0 89/46 13-4 14, Telefax: 0 89/46 13-4 33 
Hotline Do, 15-17.oo Uhr 


Manuskripteinsendungen: Manuskripte und Programmlistings werden gerne von der Redaktion angenommen. Sie müssen frei sein von Rechten Drit¬ 
ter. Sollten sie an anderer Stelle zur Veröffentlichung oder gewerblichen Nutzung angeboten worden sein, muß das angegeben werden. Mit der Einsen¬ 
dung von Manuskripten und Listings gibt der Verfasser die Zustimmung zum Abdruck in der von Markt & Technik Verlag AG herausgegebenen Publika¬ 
tionen und zur Vervielfältigung der Programmlistings auf Datenträgern. Mit Einsendung von Bauanleitungen gibt der Einsender die Zustimmung zum 
Abdruck in von Markt & Technik Vertag AG verlegten Publikationen und dazu, daß die Markt & Technik Verlag AG Geräte und Bauteile nach der Bauan¬ 
leitung herstellen läßt und vertreibt oder durch Dritte vertreiben läßt. Honorare nach Vereinbarung. Für unverlangt eingesandte Manuskripte und Listings 
wird keine Haftung übernommen. 

Layout: Ulrich Brieden, Rainer Zeitler 
Desktop Publishing: Ulrich Brieden, Rainer Zeitler 
Titelgestaltung: Ulrich Brieden. Rainer Zeitler 
Anzeigenleitung: Peter Kusterer 
Anzeigenverwaltung und Disposition: Anja Böhl (233) 

So erreichen Sie die Anzeigenabteilung: 

Tel. 0 89/46 13-9 62. Telefax: 0 89/46 13-394 


Leiter Vertriebsmarketing: Benno Gaab (740) 

Vertrieb Handel: MZV, Moderner Zeitschnftenvertrieb GmbH & Co KG. Breslauer Straße 5 , Postfach 11 23,8057 Eching, Tel. 0 89/31 90 06-0 
Erscheinungsweise: Das Sonderheft Faszination Programmieren ist zunächst zweimal jährlich geplant 
Bezugspreise: Das Einzelheft kostet DM 12.-. 

Leitung Technik: Wolfgang Meyer (887) 

Druck: L.N.Schaffrath, Grafischer Betrieb. 4170 Geldern 1 

Warenzeichen: Diese Zeitschrift steht weder direkt noch indirekt mit Commodore oder einem damit verbundenen Unternehmen in Zusammenhang. Com- 
modore ist Inhaber des Warenzeichens Amiga. 

Urheberrecht: Alle in diesem Sonderheft m erschienenen Beiträge sind urheberrechtlich geschützt. Alle Rechte, auch Übersetzungen, Vorbehalten. Repro¬ 
duktionen, gleich welcher Art, ob Fotokopie,Mikrofilm oder Erfassung in Datenverarbeitungsanlagen, nur mit schriftlicher Genehmigung des Verlags. Aus der 
Veröffentlichung kann nicht geschlossen werden, daß die beschriebene Lösung oder verwendete Bezeichnung frei von gewerblichen Schutzrechten sind. 
Haftung: Für den Fall, daß im Sonderheft unzutreffende Informationen oder in veröffentlichten Programmen oder Schaltungen Fehler enthalten sein sollten, 
kommt eine Haftung nur bei grober Fahrlässigkeit des Verlags oder seiner Mitarbeiter in Betracht. 

© 1993 Markt & Technik Verlag Aktiengesellschaft 

Vorstand: Carl-Franz von Quadt (Vors.), Lutz Glandt, Dr. Rainer Doll. Dieter Streit 
Verlagsleitung: Wolfram Höfler 
Operation Manager: Michael Koeppe 
Direktor Zeitschriften: Michael M. Pauty 

Anschrift des Verlages: Markt & Technik Verlag Aktiengesellschaft, Hans-Pinsel-Straße 2, 8013 Haar bei München 


Faszination Programmieren Nr. 1 


59 




















TIPS & TRICKS 


Suchen von Zeichenfolgen in Assembler 

Gesucht - gefunden 


Bei der Suche nach Zeichenfolgen 
kann man viel Zeit sparen, wenn 
man die richtigen Methoden 
kennt. Hier wollen wir Ihnen drei 
der schnellsten Algorithmen an 
Beispielen näherbringen. 

von Sebastian Wedeniwski 

W ir wollen im folgenden drei Suchal¬ 
gorithmen betrachten, die eine vor¬ 
gegebene Zeichenfolge (Muster) im 
vorgegebenen Speicherbereich suchen. Es 
sind dies: Brutesearch, KMPSearch und 
Mischarsearch. Zunächst eine kurze 
Beschreibung der einzelnen Algorithmen: 

Brutesearch: Dieser Algorithmus tritt in 
vielen Anwendungen auf und ist gut an die 
Architekturmerkmale der meisten Compu¬ 
tersysteme angepaßt, so daß eine optimale 
Variante einen »Standard« liefert. Bei dieser 
Suchmethode wird jede mögliche Position im 
Speicherbereich, an der das Muster passen 
könnte, überprüft, ob es tatsächlich paßt. 
Nachteil ist, daß die Suche für manche 
Muster langsam sein kann, z.B. dann, wenn 
der Text binär (aus zwei Zeichen gebildet) 
ist, wie das für Anwendungen bei der Bild¬ 
verarbeitung der Fall sein kann. 

Auf den Algorith¬ 
mus kommt's an 

KMPSearch: Die Idee, die dem von 
Knuth, Morris und Pratt entdeckten Algorith¬ 
mus zugrunde liegt, ist folgender: Wenn eine 
Nichtübereinstimmung festgestellt wird, 
besteht der »Fehlstart« aus Zeichen, die 
bereits bekannt sind (da sie sich im Muster 
befindet). Um ein einfaches Beispiel hierfür 
zu betrachten, sei angenommen, daß das erste 
Zeichen im Muster nicht noch einmal im 
Muster erscheint (z.B. 100 000). Erfolgt ein 
Fehlstart an einer gewissen Position im Spei¬ 
cherbereich, wissen wir aufgrund der Tatsa¬ 
che, daß bei den vorhergehenden Zeichen 
Übereinstimmung vorlag, daß der Speicher¬ 
zeiger nicht »zurückgesetzt« werden braucht, 
da keines der vorangehenden Zeichen im 
Speicher mit dem ersten Zeichen im Muster 
übereinstimmen kann. Das Auftreten eines 
solchen Musters ist nicht besonders wahr¬ 
scheinlich und die Implementation ist recht 
komplex. Somit ist diese Suchmethode prak¬ 
tisch recht langsam, und nur in den seltensten 
Fällen effizient. Darüber hinaus benötigt die¬ 
ser Algorithmus noch eine Tabelle mit der 


Länge des Musters, um die Sprünge zu 
gewähren. 

Mischarsearch: Dies ist der schnellste 
Algorithmus (von Boyer-Moore) von den 
erwähnten Suchmethoden, bei dem bei der 
Prüfung auf Übereinstimmung mit dem 
Muster von rechts nach links vorgegangen 
wird, und wenn sie nicht übereinstimmen, 
kann sogar festgestellt werden, daß das Zei¬ 
chen nirgends im Muster auftritt, so daß das 
Muster sofort ganz an den Zeichen vorbeige¬ 
schoben werden kann. Es wird eine Tabelle, 
mit der Länge 256 (alle Zeichen) Byte, für 
die erforderlichen Sprünge benötigt. Das 
Muster darf bei dieser Implementation nicht 
länger als 255 Zeichen sein. 

Der Einsatz der implementierten Algorith¬ 
men ist ganz einfach. Die Anfangsadresse des 
Speicherbereichs, in dem gesucht wird, muß 
im Adreßregister Al stehen und die End¬ 
adresse in A3. Die Anfangsadresse des Mu¬ 
sters muß im Adreßregister A2 stehen und 
die Endadresse in A4. Anschließend kann 
eine Suchroutine aufgerufen werden. Das 
Ergebnis steht dann im Adreßregister A0. Bei 
einer erfolglosen Suche enthält A0 die End¬ 
adresse A3. 

Als Test haben wir die drei Suchalgorith¬ 
men mit dem Suchbefehl von AMIGA 
ACTION REPLAY II mit einem beliebigen 
Muster aus fünf Zeichen verglichen. Der Ver¬ 
gleich lieferte folgendes Ergebnis: Brute¬ 
search war vier-, KMPSearch zwei- und 
Mischarsearch 15mal schneller als der Such- 
Befehl. Können Sie's noch schneller? ub 

Programmname: Suchen.asm 
Assembler: Devpac 


1: lea a,a0 ; Anfangsadresse vom Speicher 

2: lea Such.al ; Anfangsadresse vom Muster 

3: lea aend,a2 ; Endadresse vom Speicher 

4: lea Suchend,a3 ; Endadresse vom Muster 
5: ;bsr Brutesearch 
6: ;bsr Kmpsearch 

7: bsr Mischarsearch ; Ergebnis in aO 
8: rts 

9: Brutesearch: 

10: move.l al,a4 

11: BLoop: move.b (a4)+,d0 

12: cmp.b (aO)+,dO 

13: beq.s BLoop2 

14: sub.l al,a4 

15: sub.l a4,a0 

16: addq.l #l,aO 

17: move.l al,a4 

18: BLoop2: cmp.l a2,a0 

19: bge.s BEnde 

20: cmp.l a3,a4 

21: blt.s BLoop 

22: sub.l al,a3 

23: sub.l a3,a0 

24: BEnde: rts 

25: Kmpsearch: 

26: moveq #0,d0 


27: move.l dO.dl 
28: subq.b 11,dl 
29: lea skip(pc),a4 
30: lea skip+l(pc),a5 
31: move.b dl,(a4) 

32: sub.l al,a3 
33: subq #l,a3 
34: move a3,d3 

35: KLoop4: tst.b dl ; installieren 

36: blt.s KLoop 

37: move.b (al,d0.w),d2 

38: cmp.b (al,dl.w),d2 

39: beq.s KLoop 

40: move.b (a4,dl.w),dl 

41: bra.s KLoop4 

42: KLoop: addq #l,dO 

43: addq.b 11,dl 

44: move.b dl,(a5)+ 

45: cmp.b d0,d3 
46: bgt.s KLoop4 

47: moveq #0,di ; Suchalgorithmus 

48: KLoop8: tst.b dl 

49: blt.s KLoop5 

50: move.b (a0),d2 

51: cmp.b (al,dl.w),d2 

52: bne.s KLoop6 

53: KLooo5: addci.l #l,aO 

54: addq.b 11,dl 

55: cmp.l a2,a0 

56: bie.s KLoop7 

57: rts 

58: KLoop6: move.b (a4,dl.w),al 

59: KLoop7: cmp.b d3,dl 

60: bie.s KLoop8 

61: sub.l d3,a0 

62: subq.l il,aO 

63: rts 

64: Mischarsearch: 

65: move.l a3,d0 
66: sub.l al,dO 
67: lea (a0,d0.w),a0 
68: lea skip(pc),a4 
69: move.l a4,a5 

70: move.b dO,(a4)+ ; installieren 
71: move.b dO,(a4)+ 

72: move.b dO,(a4)+ 

73: move.b dO,(a4)+ 

74: move.l (a5),d0 

75: moveq 162,d7 

76: MLoop: move.l dO,(a4)+ 

77: dbf d7,MLoop 

78: move.l al,a4 

79: moveq I0,d7 

80: MLoop2: move.b (a4)+,d7 

81: subq #1,d0 

82: move.b dO,(a5,d7.w) 

83: bne.s MLoop2 

84: move.l a3,a4 ; Suchalgorithmus 

85: MLoop4: move.b -(aO),d7 

86: cmp.b -(a4),d7 

87: bne.s MLoop3 

88: cmp.l a4,al 

89: beq.s MEnde 

90: cmp.l a2,a0 

91: bie.s MLoop4 

92: MEnde: rts 

93: MLoop3: move.b (a5,d7.w),d7 

94: lea I(a0,d7.w),a0 

95: move.l a3,a4 

96: cmp.l a2,a0 

97: blt.s MLoop4 

98: move.l a2,a0 

99: rts 

100: skip: dcb.b 256,0 
101: Such: dc.b 'Suchen* 

102: Suchend: 

103: a: dc.b "Speicherbereich als Beispiel zum Su 
chen von Zeichenketten' 

104: aend: ; © 1993 M&T 

»Suchen.asm«: Drei Suchalgorithmen in 
einem Programm zum Ausprobieren 
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KNOBELECKE 


Mathematische Knobeleien 

Denksport 


Wenn Sie sich gern mit Zahlenrät¬ 
seln etc. beschäftigen, haben wir 
was für Sie: Lösungen von Lesern 
zu zwei der interessantesten Kno¬ 
belaufgaben aus der Knobelecke 
des AMIGA-Magazins. 

von Ulrich Brieden 

W er programmiert, tüftelt auch gern. 

Im AMIGA-Magazin haben wir 
deshalb speziell für Tüftler die 
Knobelecke eingerichtet. Jeden Monat finden 
Sie dort eine interessante Aufgabe aus dem 
Bereich der Mathematik etc., die es mit dem 
Computer möglichst elegant und schnell zu 
lösen gilt. Hier nun zwei Lösungsvorschläge 
zu Aufgaben des Jahres 1992: Polyominos 
und Stellensuche (ab Seite 64). 

Zu zahlreichen Aufgaben aus der Vergan¬ 
genheit liegen uns noch weitere interessante 
Lösungen vor (Damenproblem, Symbolrätsel 
lösen etc.), die wir auch gerne in diesem Son¬ 
derheft abgedruckt hätten; doch wie immer 
reicht der Platz nicht. Außerdem wollen wir 
zuerst Ihre Meinung wissen: Wünschen Sie 
mehr Lösungen zu Knobelaufgaben im 
AMIGA-Magazin oder im Sonderheft Pro¬ 
grammieren? Schreiben Sie uns, damit wir 
Ihre Wünsche in den nächsten Ausgaben 
berücksichtigen können. 


Polyominos 

In Ausgabe 6/92 des AMIGA-Magazins wurde 
ein Programm gesucht, das Polyominos berech¬ 
net. Thomas Eckloff fand eine Lösung in C. 

Die Aufgabe in Kurzform: 

Ein Polyomino (dt. »Vielzteller«) setzt sich aus 
miteinander zusammenhängenden quadrati¬ 
schen Zellen zusammen. Es gibt insgesamt fünf 
verschiedene Tetraminos und zwölf verschie¬ 
dene Pentominos. Dabei heißen zwei Steine 
verschieden, wenn sie sich nicht durch Ver¬ 
schiebung, Drehung oder Spiegelung ineinan¬ 
der überführen lassen. Die Tabelle »Verschie¬ 
dene Polyominos« gibt die Anzahl der ver¬ 
schiedenen Möglichkeiten für die ersten Polyo¬ 
minos mit bis zu sechs Zellen wieder. 

Und nun zur Aufgabe! Versuchen Sie, mit 
Hilfe ihres Amiga die Tabelle zu vervollständi¬ 
gen. 


von Thomas Eckloff 

Falls man versucht, zur Lösung der Auf¬ 
gabe die brute-force-Methode anzuwenden, 
wird man schnell merken, daß die Rechenzeit 
mit der Zahl der zu berechnenden Teile des 
Poliominos extrem ansteigt. Schon ab sechs 


bis sieben Steinen ist nicht absehbar, wann 
das Programm fertig sein wird. Die in der 
Aufgabe geforderten 12 Steine zu berechnen, 
ist so unmöglich. 

Es gilt also, Ansätze zu finden, das lang¬ 
wierige Durchsuchen der vorhanden Poliomi¬ 
nos zu verkürzen. Die erste deutlich Verkür¬ 
zung der Rechenzeit erreicht man, wenn man 
alle Polyominos immer quer speichert, d.h. 
die breite Seite horizontal. 

Dadurch benötigt man für alle nicht recht¬ 
eckigen Bilder nur vier Darstellungen. 
Außerdem muß man nur Bilder vergleichen, 
die dieselbe Höhe und Breite haben; die 
Rechenzeit reduziert sich dadurch deutlich. 

Als nächsten Schritt kann man für den Ein¬ 
stieg in die Liste der Bilder eine Indextabelle 
erstellen, über die man Zugriff auf Höhe und 
Breite der Teile hat. Ein Programm muß dann 
nicht mehr die ganze Tabelle durcharbeiten, 
sondern kann über die Indizes an die zu ver¬ 
gleichenden Werte kommen. Die Rechenzeit 
verkürzt sich hierdurch erneut um ein Vielfa¬ 
ches. 


Ein weiterer Schritt ist es, die Indextabelle 
zu vergrößern: Über einen Hash-Code kann 
man Eigenschaften eines Bilds in der Tabelle 
integrieren, die einen Vergleich erleichtert. 

Eine weitere zeitaufwendige Sache ist das 
ständige Spiegeln und Drehen der Bilder. 
Falls man die Teile richtig speichert, geht das 
Ganze relativ schnell. Das vorgestellte Pro¬ 
gramm »Polyominos.c« speichert alle Polyo- 
minios in einer eindeutigen Weise: 

Vor dem Durchsuchen prüft es alle acht 
Perspektiven und merkt sich die höchstwer¬ 
tige. Das ist die Position, die den höchsten 
Wert darstellt, wenn man sich das Polyomino 
als Bitmuster vorstellt. Von links nach rechts 
und dann von oben nach unten betrachtet. 
Durch dieses Verfahren wird jedes neue Bild 
automatisch höchstwertig und so gespeichert. 
Jedes neue Bild muß also nur höchstwertig 
erklärt zu werden und kann ohne jede weitere 
Drehung etc, in die Liste eingetragen werden. 
Beispiel ein Polyomino mit vier Steinen: 

# 100 # 001 ### 111 ### 111 

### 111 ### 111 # 100 # 001 

Es gibt nur vier Möglichkeiten, weil das 
Bild immer quer gespeichert wird. In diesem 
Fall würde das dritte Bild mit der Bit-Kombi¬ 
nation 111 100 gespeichert. 


Bei abnehmender Rechenzeit erlangt nun 
ein zweites Problem Bedeutung: Der Spei¬ 
cherplatz wird knapp. 

Nehmen wir z.B. die Darstellung »ein 
Stein entspricht einem Byte«. Für ein 12er 
Polyomino benötigt man eine 12 * 12-Matrix. 
Bei ca. 70 000 möglichen Poliominos ergibt 
das einen Speicherbedarf von 12 12 * 70 000 
Byte. Das erfordert nur für die Bilder ca. 10 
MByte Speicherbedarf . Ganz abgesehen von 
der restlichen Informationen, die zu jedem 
Bild benötigt werden. 

Auch mit der Tatsache, daß ein 12er-Poly- 
omino maximal sechs Zeilen hoch sein kann, 
da es immer quer gespeichert wird, kann man 
zwar noch 5 MByte sparen, benötigt aber 
immer noch mehr Speicher als die meisten 
Amiga-Besitzer haben. 

Bei der bitweisen Darstellung benötigt man 
für eine Zeile maximal 12 Bits. Es bietet sich 
eine Darstellung in einem Wort (16 Bit) an. 
Bei sechs Zeilen Höhe ergibt sich ein Spei¬ 
cherbedarf pro Bildinformation von 12 Byte. 
Die Folge wäre ein Speicherbedarf von 12 * 
70 000 = 840 000 Byte für alle Kombinatio¬ 
nen. Zu jedem Bild werden noch einmal 4 
Byte für die Prüfsumme (Koordinaten + 
Hashwert) und vier Byte für den Zeiger auf 
den nächsten Eintrag benötigt, also nochmals 
70 000 * 8 = 560 000 Byte. 

Nun hat das Amiga-Betriebssystem die 
Eigenschaft, sich den Speicher immer in 
Vielfachen von acht Byte zu reservieren. Es 


würden also nicht nur 12+4+4 = 20 Byte son¬ 
dern auf das nächste Vielfache von acht auf¬ 
gerundet, also 24 Byte, reserviert werden. 
Der Speicherbedarf für eine Liste mit 70 000 
Einträgen betrüge also 24 * 70 000 = 1,68 
MByte. 

Eine bessere Möglichkeit der Bilddarstel¬ 
lung bietet der folgende - zunächst unsinnig 
erscheindende - Vorschlag, zu jedem Stein 
zusätzlich seine Koordinaten zu speichern. 12 
Steine mit je zwei Koordinaten wären indis¬ 
kutabel. Bei näherer Betrachtung erkennt 
man jedoch, daß man mit einem Halbbyte (4 
Bit) eine Ordinate darstellen kann. (Werte 0 
bis 15). Es fällt auf, daß man für jeden Steine 
nur einen Wert sichern muß: die Position des 
Steins in einer Zeile. Beispiel: 

###.## 

.####. 

Dieses Bild hätte die interne Darstellung 
zur Folge: 

1,2,3,5,6,2,3,4,5 

Ist in so einer Zahlenreihe ein Wert kleiner 
oder gleich dem vorherigen, hat ein Zeilen¬ 
wechsel stattgefunden. Ist er größer als der 
Vorherige, ist der Stein noch in derselben 
Zeile. Das ist eine Eigenschaft der Polyomi- 
nios, da immer eine Verbindung zur oberen 


VERSCHIEDENE POLYOMINOS (n-ZELLER) 


n =123456 7 8 9 10 11 12 

Anzahl =1125 12 35 ? ? ?? ? ? 
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Zeile bestehen muß. Um 12 Steine Steine zu 
speichern, werden nun nur noch 12 Halbbyte 
also 6 Byte benötigt. Diese 6 Byte zusammen 
mit den 8 Byte für Checksumme und Zeiger 
ergeben 14 Byte. Das System belegt aller¬ 
dings 16 Byte, d.h. wir vergeuden 2 Byte. 

Was soll's? Insgesammt braucht man nur 
16 * 70 000 =1,12 MByte. Das sollte für die 
meisten Amiga-Besitzer machbar sein. 

Da eine Liste von z.B. 10er_Polyominos 
aus einer Liste von 9er Polyominos aufgebaut 
wird, sind immer zwei Listen im Speicher. 
Die alte Liste ist jedoch immer deutlich klei¬ 
ner als die folgende. Jeder Amiga mit 2 
MByte sollte in der Lage sein, ein 12er 
Poliomnos zu erzeugen. Die echte Anzahl der 
12er-Polyominos stellt sich mit 63 600 recht 
nahan den geschätzten 70 000. 

Um das Ganze noch zu vereinfachen, kann 
man nun folgendes machen. 63 600 Spei¬ 


cheranforderungen belasten das System, 
zumal man ebensoviele Bereiche am Ende 
wieder freigeben muß. Es bietet sich also 
zusätzlich an, eine eigene Speicherverwal¬ 
tung einzusetzen, die z.B. wie im Beispiel¬ 
programm nur alle 100 Bilder Speicher reser¬ 
viert, der 100 Bilder aufnimmt. Hierdurch 
verdoppelt sich die Rechengeschwindigkeit 
im Vergleich zur ersten Methode. 

Um alle 63600 Kombinationen mit 12 Stei¬ 
nen zu berechnen, benötigt ein Amiga mit 
A2630 Turbokarte (25 MHz) etwa 8 Minu¬ 
ten. Ein normaler Amiga rund eine Stunde. 


POLYOMI NOS 


n 7 8 9 10 11 12 13 14 

Zahl 108 369 1285 4655 17073 63600 238591 901971 


Das Programm ist in C-Standard verfaßt, 
und enthält keinen Amiga-spezifischen Auf¬ 
ruf. Es läuft genauso unter MS-DOS mit 
Turbo C und unter Unix auf einer Sun-Work- 
station (SunOS). Der Autor schaffte mit der 
Amiga-Version die Berechnung von 13er- 
Polyominos (238 591). Die Sun-Workstation 
berechnete 14er Polyominos in knapp 35 
Minuten (901 971). Die Tabelle zeigt die 
gesuchten Werte. 

Mit dem Programm sind maximal 14er 
Polyominos berechenbar. Der Aufwand für 
die Berechnung größerer Polyominos ist 
gering und liegt hauptsächlich in der Ände¬ 
rung vom Halbbyte auf Byte bei der internen 
Bilddarstellung. Das Programm benötigt zwei 
Parameter: Der erste gibt die Anzahl der 
gewünschten Steine an und der zweite die 
Breite der Ausgabe. Der zweite Parameter ist 
optional und beträgt standardmäßig 79. ub 


1 

struct pol 

51: pold2=(struct pol *)malloc((int)256); 


tteten Listen für die Polyominos und die S 

2 

{ 

unsigned long x,y; 

52: pold2->x=polineu; 


peicherverwaltung */ 

3 

53: pold2->y=polineu; 

103 

memp2=(struct meml *)-lL; 

4 

unsigned long cs; 

54: pold2->image=malloc((int)256); 

104 

memakt=(struct-meml *)-lL; 

5 

unsigned char *image; 

55: pold2->np=(struct pol *)-lL; 

105 

poll=sizeof(struct pol); /* Dabei wird da 

6 

struct pol *np; 

56: /* In diesen Zwischenspeichern wird jeder 


s Ausgangspolyomino (ein einziger Stein) ■ 

7 

}; 

gesetzte Stein in */ 


per Hand" erzeugt */ 

8 

struct poln 

57: /* einem Byte abgelegt, was bei späteren 

106: polnl=sizeof(struct poln); 

9 

{ unsigned long cs; 

Manipulationen (Drehung, Spiegelung, etc.) 

107 

poli=l; 

10 

unsigned char image[8]; 

schneller ist als bei bit orientierter Sp 

108 

palt=(struct poln *)-lL; 

11 

struct poln *np; 

eicherung. */ 

109 

pneu= (struct poln *) malloc ownO? 

12 

}; 

58: pold3=(struct pol *)malloc{(int)poll); 

110 

pneu->cs=0x00000011; 

13 

struct meml 

59: pold3->x=polineu; 

111 

pneu->image(0]=0xl0; 

14 

{ struct poln sp[100]; 

60: pold3->y=polineu; 

112 

pneu->np=(struct poln *)-lL; 

15 

struct meml *nm; 

61: pold3->image=malloc((int)256); 

113 

tiefe=l; 

16 

}; 

62: pold3->np=(struct pol *)-lL; 

114 

) 

17 

struct pol *poldl,*pold2,*pold3,*pold4; 

63: pold4=(struct pol *)malloc((int)poll); /* 

115 

Poli 10 

18 

struct poln *palt,*pneu,*lpoff,*poldn,*pl, 

Struktur pol -> byteweise */ 

116 

{register unsigned long i; 


*poff; 

64: pold4->x=polineu; /* Struktur poln -> 

117: /* In dieser Routine wird die jeweils zul 

19: unsigned long poll,polnl,poli,polineu,poli 
n,polipix,polix,poliy,offx,offy,tiefe,h,b, 

bitweise */ 

65: pold4->y=polineu; 


etzt erzeugte Liste mit Polyominos abgearb 
eitet und die neue Liste aufgebaut */ 


dis=80L,anz=0,anzx,anzd,ox,oy,adr,pich,pic 

66: pold4->image=malloc((int)256); 

118 

struct poln *pl; 


b,pico,picn,picz=500,ent=8192,blks=100,mem 

67: pold4->np=(struct pol *)-lL; 

119 

polineu=poli+2; 


p,interv; 

68: poldn=(struct poln *)malloc((int)polnl); 

120 

palt=pneu; 

20: voia *malloc{); 

/* Initialisieren einer poin-Struktur */ 

121 

anzx=0; 

21 

struct meml *malloc_own(); 

69: poldn->np=(struct poln *)-lL; 

122 

pneu=(struct poln *)-lL; 

22 

unsigned char *imagex,imageh[16],*bild; 

70: PoliominoO; /* Aufruf Hauptprogramm */ 

123 

poff=(struct poln *)-lL; 

23 

struct poln **Entry; 

71: anzd=picn=pico=pich=picb=0; 

124 

mempl=memp2; 

24 

struct meml *mempl,*memp2,*memakt; 

72: ClearlmageO; /* Löschen des Ausgabebereichs*/ 

125 

memakt=(struct meml *)-lL; 

25 

main(argc.argv) 

73: while(pneu != (struct poln *)-lL) /* Aba 

126 

memp=blks+l; 

26 

int arge; 

rbeiten der Liste der erzeugten Polyominos 

127 

for(i=0;i<ent;i++) /*Löschen der Hashtabelle*/ 

27 

unsigned char *argv[]; 

und Ausgabe + Zählen */ 

128 

Entry[i]=0L; 

28 

{struct poln *pl; 

74: { if(dis > OL) 

129 

anzd=0; 

29 

if(argc < 2) /* Wenn kein Parameter angeg 

7 5: PicOut(pneu,polineu); 

130 

interv=0; 

30 

eben wurde, standardmäßig 5 Steine */ 

76: anzd++; 

131 

whiletpalt != (struct poln *)-lL) 

polin=5; 

77: pl=pneu; 

132 

/* Abarbeiten der alten Liste */ 

31 

eise /* sonst Anzahl nach >polin< */ 

78: pneu=pneu->np; 

133 

{ /* und Aufruf eines Unterprogramms, das 

32 

sscanf (argv[l], "%ld\&polin); 

79: } 


aus jedem alten Bild versucht, mehrere ne 

33 

if(argc > 2) /* Zeichen je Zeile für Ausg 

80: mempl=memp2; 


ue zu erstellen */ 


abe - Standard 80, bei 0 keine A. */ 

81: free_own(); /* Freigeben des Speichers * / 

134 

Poli_2 (); 

34 

sscanf(argv[2],"lld\&dis); 

82: if(dis > OL) /* Ausgeben des letzten Ausg 

135 

pl=palt; 

35 

Entry=(struct poln **) malloc((int)(ent*4 

abebereichs */ 

136 

palt=palt->np; 

) 


)); /* Speicher für Hashtabelle reservieren */ 

83: Out_Line(); 

137 

36 

if(lEntry) 

84: free(poldn,polnl); /* Freigabe des Speie 

138 

free ownO; /* Freigabe des */ 

37 

printf ("\nFehler bei mallocVn*); 

her der Zwischenstrukturen */ 

139 

/* Speichers der alten Struktur */ 

38 

bild=malloc((int)(picz*16)); /* Speiche 

r für Ausgabebereich reservieren (500 x 16 

85: free(pold4->image,256); 

86: free(pold4,poli); 

140 

printf(*%101d%101d\n",poli+l,anzd); /* A 
usgabe eines Zwischenstandes */ 


Zeichen) */ 

87: free(pold3->image,256); 

141 

) 

39 

if(ibild) 

88: free(pold3,poll); 

142 

Poli 2() 

40 

printf("NnFehler bei malloc\n*); 

89: free(pold2->image,256); 

143 

{register unsigned long i,j; 

41 

InitO; /* Diverse Initialisierungen */ 

90: free(pöld2,poli); 

144 

register unsigned char *pl,*p2; 

42 

mempl=(struct meml *)-lL; /* Pointer für 

91: free(poldl->image,256); 

145 

j=256; 

43 

eigene Speicherverwaltung initialisieren */ 

92: free(poldl,poli); 

146 

pl=poldl->image; 

memp2=(struct meml *)-lL; 

93: free(bild,picz*16L); /* Freigabe des Ausg 

147 

p2=pold2->image; 

44 

poldl=(struct pol *) malloc((int)poll); 

abebereichs */ 

148 

for(i=0;i<j;i++) /* Löschen der Bildspeicher*/ 

45 

/* Initialisieren von vier Zwischenspeich 

94: free(Entry,ent*4L); /* Freigabe der Hash 

149 

{ /* von poldl und pold2 */ 


em für die interne Darstellung der Polyom 

tabeile */ 

150 

*pl++=0; 


inos mit 16 x 16 Punkten. Die Größe wurde */ 

95: printf(■ \n%101d Poliominos ermittelt\n",anzd); 

151 

*p2++=0; 

) 

46 

/* aus dem Grunde statisch gewählt, da so 

96: } 

152 


bei der Adressberechnung statt einer Mult 

97: PoliominoO 

153 

Unpack(palt); /* Entpacken des nächsten */ 


iplikation ein Linksshift um vier Bits mög ' 

98: (for(poli=l;poli<polin;poli++) 

154 

/* Eintrags in der Liste */ 

47 

lieh ist. */ 

/* Hauptschleife */ 

155 

pl=poldl->image; 

poldl->x=polineu; 

99: Poli_l{); 

156 

p2=pold2->image? 

48 

poldl->y=polineu; 

100: } 

157 

for(i=l;i<=poldl->y;i++) 

49 

poldl->image=malloc((int)256); 

101: InitO 

158 

/* Das entpackte Bild wird Zeile für Zeil 

50 

poldl->np=(struct pol *)-lL; 

102: {menp=blks+l; /* Initialisierung der verke 


e, Zeichen für Zeichen abgearbeitet. Bei e 
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inem nicht leeren Feld wird versucht, oben 
, unten, rechts und links ein Stein anzufügen*/ 
159: for(j=l;j<=poldl->x;j++) 

160: if {* (pl+(i«4)+j) != 0) 

161: { Poli_5(pl,p2,i,j-1); 

162: Poli_5(pl,p2,i-l,j); 

163: Poli_5(pl,p2,i,j+1); 

164: Poli_5(pl,p2,i+l,j); 

165: } 

166: } 

167: Poli_5(pl,p2,x,y) 

168: register unsigned char *pl,*p2; 

169: register unsigned long x,y; 

170: {register unsigned long xl? 

171: xl=(x«4)+y; 

172: if{*(p2+xl) == 1) /* Wenn dort schon ein 
Stein war */ 

173: retum(O); /* ->Rücksprung */ 

174: *(pl+xl)=1; /* Einträgen des Steins 

*/ 

175: *(p2+xl)=l; /* Position als besetzt k 

ennzeichnen */ 

176: ox=l; /* Feststellen, ob sich die Höhe */ 

177: oy=l; /* oder die Breite geändert hat */ 

178: b=poldl->x; /* oder ob in den oberen oder */ 
179: h=poldl->y; /* linken Rahmen geschrieben 
wurde */ 

180: if(x == OL) 

181: { ox—; 

182: h++; 

183: ) 

184: if(x > h) 

185: h++; 

186: if(y == OL) 

187: { oy~; 

188: b++; 

189: ) 

190: if(y > b) 

191: b++; 

192: Poii_7(x,y); 

193: *(pl+xl)=0; /* Herstellen der Origina 

lbildes */ 

194: } 

195: Poli_7(x,y) 

196: unsigned long x,y; 

197: {register unsigned char *pl,*p2; 

198: /* Das neu entstandene Bild wird bündig n 

ach oben links ausgerichtet. */ 

199: register unsigned long i,j,l; 

200: pl=poldl->image+(ox«4)+oy; 

201: p2=pold3->image; 

202: pold3->x=b; 

203: pold3->y=h; 

204: for(i=0;i<h;i++) 

205: { for{j=0?j<b;j++) 

206: *p2++=*pl++; 

207: pl+=(16-b); 

208: p2+=(16-b); 

209: } 

210: if(h > b) /* Wenn die Höhe des Bildes */ 
211: Rot_90(); /* größer ist als die Breite 

, wird es um 90 Grad gedreht */ 

212: Poli_9 (); 

213: } 

214: Rot_90() 

215: {register unsigned char *pl,*p2,Zeichen; / 

* In diesen Unterprogramm */ 

216: register unsigned long i,j,il,i2,x; /* f 
indet die Drehung durch Spiegelung an der 
Diagonalen statt */ 

217: pl=pold3->image; 

218: x=pold3->x; 

219: pold3->x=pold3->y; 

220: pold3->y=x; 

221: pl=pold3->image; 

222: p2=pold3->image; 

223: for(i=0;i<pold3->x;i++) 

224: { il=i«4; 

225: i2=i; 

226: for(j=0;j<i;j++) 

227: { zeichen=*(pl+il); 

228: Mpl+il)=*(p2+i2); 

229: Mp2+i2)=zeichen; 

230: il++; 

231: i2+=16; 

232: } 

233: ) 

234: } 

235: Poli_9 () 

236: {register struct poln *pl,*p2; 

237: register unsigned long i,k,offset; 

238: pl=pneu; 

239: p2=(struct poln *)-lL; 

240: NormalizeO; /* Beschreibung siehe Routine */ 
241: Copy_Pol(pold3,pold4); /* Es wird das hö 

chstwertige Bild übernommen */ 


242: ChecksumO; /* Ermitteln des Hashindexes */ 
243: Pack(pold3)? /* Packen zum Vergleich */ 
244: adr=poldn->cs»8; /* Hashadresse ermitteln */ 
245: for(i=adr;i>0;i--) 

246: { if(Entry[i] ! = 0L) /* Ersten Eintrag < 

= dem gesuchten ermitteln */ 

247: { pl=Entry[i]; 

248: break; 

249: } 

250: } 

251: k=0; 

252: while((pl != (struct poln *)-lL) && (k == 

0)) /* Durchsuchen der vorhandenen Bilder */ 
253: { if ((pl->cs»8) > adr) 

254: break; 

255: if(pl->cs == poldn->cs) 

256: if (stmcmp(pl->image,poldn->image,8) == 0) 

257: k=l; 

258: eise 

259: k=0; 

260: p2=pl; 

261: pl=pl->np; 

262: } 

263: if(k == 1) /* schon vorhanden -> Rücksprung */ 

264: retum(O); 

265: Poli_10(pl,p2); /* Aufnehmen des Bildes */ 
266: ) 

267: Poli_10(lp,lp2) 

268: struct poln *lp,*lp2; 

269: {register struct poln *pl; /* Einstellen 
in die Kette */ 

270: register unsigned char *p2,*p3; 

271: register unsigned long i,j; 

272: pl=poff; 

273: poff=(struct poln *)malloc_öwn(); 

274: poff->cs=poldn->cs; 

275: strncpy(poff->image,poldn->image,8); 

276: poff->np=lp; 

277: if((lp == (struct poln *)-lL) && (lp2 == 
(struct poln *)-1L)) 

278: pneu=poff; 

279: eise 

280: if(lp2 == (struct poln *)-lL) 

281: { pneu=pof f; 

282: poff->np=lp; 

283: } 

284: eise 

285: lp2->np=poff; 

286: if(Entry[adr] == 0L) /* Eintrag in die 

Hashtabelle */ 

287: Entry[adr] = poff; 

288: anzd++; 

289: interv++; 

290: if(interv == 100) /* Alle 100 neuen Bi 

lder auf dem Bildschirm zeigen */ 

291: { printf(* %101d%101d\r* ,poli+1,anzd); 

292: interv=0; 

293: } 

294: } 

295: Mirror_H() /* Die Routine spiegelt ein */ 
296: { /* Bild horizontal */ 

297: struct pol *pl; 

298: register unsigned char *p3,*p4,Zeichen,*p2; 
299: register unsigned long i,j,k,l; 

300: l=pold3->x/2; 

301: pl=pold3; 

302: p2=pl->image; 

303: for(i=0;i<pold3->y;i++) 

304: { k=pold3->x-l; 

305: p3=p2+pold3->x; 

306: p4=p2; 

307: for(j=0;j <1;j++) 

308: { zeichen=*p4; 

309: *(p4++)=*(--p3); 

310: *p3=zeichen; 

311: } 

312: p2+=16; 

313: } 

314: } 

315: Mirror_V() /* Die Routine spiegelt ein */ 
316: { /* Bild vertikal */ 

317: struct pol *pl; 

318: register unsigned char *p3,*p4,Zeichen,*p2; 
319: register unsigned long i,j,k,1; 

320: pl=pold3; 

321: p2=pl->image; 

322: k=0; 

323: 1= (pold3->y-l) «4; 

324: for(i=0;i<pold3->y/2;i++) 

325: { p3=p2+k; 

326: p4=p2+l; 

327: for(j=0;j<pold3->x;j++) 

328: { zeichen=*p3; 

329: *(p3++)=*p4; 

330: *(p4++)=zeichen; 

331: } • 


332: k+=16; 

333: 1-=16; 

334: } 

335: } 

336: Copy_Pol(pl,p2) /* Die Routine kopiert eine */ 
337: struct pol *pl,*p2; /* komplette Struktur */ 
338: {register unsigned char *p3,*p4; 

339: register unsigned long i,j,k; 

340: p3=pl->image; 

341: p4=p2->image; 

342: k=pold3->x; 

343: for(i=0;i<pold3->y;i++) 

344: {for(j=0;j<k;j++) 

345: *p3++=*p4++; 

346: p3+=16-k; 

347: p4+=16-k; 

348: ) 

349: } 

350: Cmp_Pol(pl,p2) /* Die Routine vergleicht V 
351: struct pol *pl,*p2; /* zwei Bilder */ 

352: {register unsigned char *p3,*p4; 

353: register unsigned long i,j,k; 

354: p3=pl->image; 

355: p4=p2->image; 

356: for(i=0;i<pold3->y;i++) 

357: for(j=0;j<pold3->x;j++) 

358: { k=*(p3+(i«4)+j ); 

359: k=k-* (p4-*-(i«4)+j); 

360: if(k != 0) 

361: retum(k); 

362: ) 

363: retum(O); 

364: } 

365: NormalizeO /* Hier wird das */ 

366: { /* Bild auf alle möglichen V 

367: Copy_Pol(pold4,pold3); /‘Darstellungeng 
edreht und gespiegelt. */ 

368: Mirror_H(); /* Dabei wird das Bild mit d 

er höchsten Wertigkeit, d. h. */ 

369: if(Cmp_Pol(pold3,pold4) >0) /‘mit dem 
frühesten Auftreten */ 

370: Copy_Pol(pold4,pold3); /* ausgefüllt 

er Felder (von */ 

371: /* rechts nach links und von */ 

372: Mirror_V(); /* oben nach unten) in pold4 */ 
373: if(Cmp_Pol(pold3,pold4) > 0) /* abgelegt.*/ 

374: Copy_Pol(pold4,pold3); 

375: Mirror.HO; 

376: if(Cmp_Pol(pold3,pold4) > 0) 

377: Copy_Pol(pold4,pold3); 

378: if(pold3->x != pold3->y) 

379: retum(O); 

380: Rot_90 (); 

381: if(Cnp_Pol(pold3,pold4) > 0) 

382: Copy_Pol(pold4,pold3); 

383: Mirror.HO; 

384: if(Cmp_Pol(pold3,pold4) > 0) 

385: Copy_Pol(pold4,pold3); 

386: Mirror.VO; 

387: if(Cmp_Pol(pold3,pold4) > 0) 

388: Copy.Pol(pold4,pold3); 

389: Mirror_H(); 

390: if(Cmp_Pol(pold3,pold4) > 0) 

391: Copy_Pol(pold4,pold3); 

392: retum(O); 

393: } 

394: ChecksumO /* Ermitteln der Checksumme */ 
395: {register unsigned char *pl; 

396: register unsigned long i,j,k,1; 

397: k=0; 

398: 1=0; 

399: pl=pold3->image; 

400: for(i=0;i<pold3->y;i++) 

401: for(j=0;j<pold3->x;j++) 

402: k+= (* (pl+ (i«4) +j) *i«10+j) ; 

403: } 

404: Unpack(p) /* Entpacken eines Bildes */ 

405: struct poln *p; 

406: {register unsigned char *pl,*p2,*p3; 

407: register unsigned long i,j,k,ln,la,x,y; 

408: i=p->cs&0xff; 

409: x=i/16; 

410: y=i&0xf; 

411: j=0; 

412: poldl->x=x; 

413: poldl->y=y; 

414: pl=poldl->image; 

415: p2=pold2->image; 

416: imagex=(unsigned char *) &p->image{0]; 

417: p3=&imageh[0]; 

418: for(i=0;i<8;i++) 

419: { j=imagex[i]; 

420: *p3++=(j»4)&0xf; 

421: *p3++=j&0xf; 

422: } 

423: x=0; 


Faszination Programmieren Nr.l 
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424 

V=0; 

470 

register unsigned long n; 

515 

print f (•-\n"); 

425 

la=99; 

471 

{unsigned char *pl,*p2,*p3; 

516 

pich=0; 

426 

for(k=0;k<poli;k++) 

472 

unsigned long i,j,k,ln,la,x,y,h,b; 

517 

picb=0; 

427 

{ ln=imageh[kj; 

473 

anz++; 

518 

pico=0; 

428 

if(ln <=la) 

474 

i=p->cs&0xff; 

519 

ClearImage(); 

} 

429 

y++; 

475 

x=i/16; 

520 

430 

x=ln; 

476 

y=i&0xf; 

521 

ClearImage() 

431 

la=ln; 

477 

3=0; 

522 

{register unsigned char *pl; 

432 

*{pl+(y«4)+x)=l; 

478 

b=x; 

523 

register unsigned long i,j; 

433 

*(p2+(y«4)+x)=l; 

479 

h=y; 

524 

pl=bild; 

434 

} 

480 

if(pico + b > dis) 

525 

for(i=0;i<picz*16;i++) 

435 

} 

481 

Out_Line(); 

526 

*pl++=’ '; 

) 

436 

Pack(p) /* Packen eines Bildes */ 

482 

if(h > pich) 

527 

437 

struct pol *p; 

483 

pich=h; 

528: struct meml *malloc own() /* eigene Spei 

438 

(register unsigned long i,j,k,l,m; 

484 

x=0; 


Oberverwaltung dadurch muß nur alle 100 */ 

{ 

439 

register unsigned char *pl,*p2; 

485 

y=0; 

529 

440 

pl=p->image; 

486 

la=0; 

530: register struct meml *pl; /* Bilder ein 

441 

p2=&imageh[0]; 

487 

imagex=(unsigned char *) &p->image[0]; 


malloc durchgeführt werden. */ 

442 

for(i=0;i<16;i++) 

488 

p3=&imageh(0]; 

531 

memp++; 

443 

*p2++=Q; 

489 

for(i=0;i<8;i++) 

532 

iflmemp >= blks) 

444 

p2=&imageh[0]; 

490 

{ j=imagex(i]; 

533 

{ memp=Q; 

445 

k=0; 

491 

*p3++=(j»4)&0xf; 

534 

pl=memakt; 

446 

for(i=0;i<p->y;i++) 

492 

*p3++=j&0xf; 

535 

memakt=(struct meml *)malloc(sizeof (s 

447 

( 1=0; 

493 

} 


truct meml)); 

448 

for(j=0;j<p->x;j++) 

494 

x=0; 

536 

if(pl == (struct meml *)-lL) 

449 

{ m=*(pl+(i«4)+j); 

495 

y=0; 

537 

memp2=memakt; 

450 

if(m != 0) 

496 

la=0; 

538 

eise 

451 

{ *p2++=j+l; 

497 

k=0; 

539 

pl->nm=memakt; 

452 

l+= (l«j) ; 



540 

memakt->nm=(struct mel *)-lL; 

} 

453 

) 

498 

while(ln=imageh[k]) 

541 

454 

} 

k=k A l; 

499 

{ k++; 

542 

retum( (struct meml *)&memakt->sp[memp)) ; 

) 

455 

500 

if(ln <=la) 

543 

456 

k*=9; 

501 

y++; 

544 

free_own() /* Freigabe der Speicherliste*/ 

457 

} 

p2=&imageh[Q]; 

502 

x=ln; 

545 

{register struct meml *pl,*p2; 

458 

503 

la=ln; 

546 

pl=mempl; 

459 

imagex=(unsigned char *) &poldn->image[0]; 

504 

x—; 

547 

while(pl != (struct meml *)-lL) 

460 

for(i=0;i<8;i++) , 

505 

* (bild+pico+y*picz+x)= ’ 1» ’ ; 

548 

{ p2=pl; 

461 

{ j=*p2++«4; 

506 

) 

549 

pl=pl->nm; 

462 

j+=*p2++; 

507 

pico+=b+l; 

550 

free(p2,sizeof(struct meml)); 

} 

463 

imagex[i]=j; 

508 

) 

551 

464 

) 

509 

Out_Line() 

552 

) 

465 

poldn->cs=pold3->x*16+pold3->y; 

510 

{register unsigned long i,j; 
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466 

poldn->cs+=( (k&0xlfff)«8); 

511 

for{i=0;i<pich;i++) 



467 

468 

) 

PicOut(p,n) /* Ausgabe der Polyominos */ 

512 

513 

{ *(bild+i*picz+pico)=0; 
print f ("%s\n\bild+i*picz) ; 

) 

»Polyominios.c«: Das Programm berech- 

469 

register struct poln *p; 

514 

net Polyominos mit bis zu 14 Teilen 


Amiga geht auf 
Stellensuche 

In der Knobelecke 9/1992 des AMIGA- 
Magazins stellten wir die Aufgabe, ein Pro¬ 
gramm zu schreiben, um Pi auf möglichst 
viele Stellen zu berechen. Heiko Hirschmül¬ 
ler aus schaffte mit einem Assembler-Pro¬ 
gramm die Millionengrenze. 


von Heiko Hirschmüller 

Das Programm »Pi.c« wird vom CLI mit 
Pi n (bzw. Pi n »Datei) 

gestartet, wobei n die Anzahl der gewünsch¬ 
ten Nachkommastellen ist. (Bsp. »Pi 2000«, 
berechnet Pi mit 2000 Nachkommastellen 
und gibt das Ergebnis auf dem Bildschirm 
aus.) Die Zahl n sollte zwischen 12 und 1 000 
000 liegen und wird intern gerundet, so daß 
sie ohne Rest durch 4 teilbar ist. 
Funktionsweise des Programms: 

Das Programm berechnet Pi nach : 

Pi = 48*arctan (1/18) + 32*arctan (1/57) - 
20*arctan (1/239) 

wobei der arctan durch die Taylor'sehe Reihe 
arctan (x) = x - x A 3/3 + x A 5/5 - x A 7/7 + ... 
angenähert wird. 

Nach dem Einlesen der gewünschten Stel¬ 
lenanzahl aus der Kommandozeile und dem 
Öffnen der »dos.library« wird der benötigte 
Speicher reserviert. Nun werden nacheinan¬ 
der die drei arctan-Terme berechnet. Dabei 


wird zunächst der Zähler (z.B. 48 beim 1. 
Term) in den Speicherbereich des Summan¬ 
den geschrieben (nach dem 1. Wort beginnen 
die Nachkommastellen). Danach wird der 
Summand durch das Argument geteilt (Beim 

I. Term 18) und anschließend wird der Sum¬ 
mand (der nun das 1. Glied des Taylorpoly¬ 
noms ist) zur Summe hinzuaddiert (oder Sub- 
tra hiert beim 3. Term). 

In der folgenden Schleife wird jeweils das 
folgende Glied der Taylorreihe berechnet 
(Summand:=Summand/(Argument A 2) und 
Zwischenspeicher:=Summand/i, wobei Argu¬ 
ment beim 1. Term 18 ist und i := 3, 5, 7, 9, 

II, ...) und abwechselnd zur Summe addiert 
oder davon abgezogen. Die Schleife wird 
solange durchlaufen, bis der Summand null 
ist. Danach folgt die Umrechnung in eine 
Dezimalzahl und Ausgabe auf dem Bild¬ 
schirm in ähnlicher Weise wie beim Beispiel¬ 
programm (Berechnung von e) AMIGA- 
Magazin 9/92, Seite 58) 

Es bleibt noch zu bemerken, daß das 
gesammte Programm zur Berechnung von Pi 
mit mehr als 1 Million Stellen ausgelegt ist. 
Insbesondere mußte der Autor eine Divisi¬ 
onsart finden, bei welcher der Divisor größer 
als 65535 ist, sonst wäre eine Berechnung 
von Pi nur mit max. 82 268 Stellen möglich. 
Im zugehörigen Programmteil wird der Divi¬ 
sor zunächst auf einen 16-Bit-Wert vermin¬ 
dert, um so (durch normale Division) daß 
Ergebnis abzuschätzen. Danach wird das 
Ergebnis und der Rest noch korregiert (Die 
Kommentare im Source-Code dürften zum 


Verständnis ausreichen). 

Der Rundungsfehler bei 250000 Stellen 
dürfte maximal die letzten sechs Stellen 
betreffen. Zur Berechnung des 1. Terms sind 
199 157 Glieder notwendig, bei denen maxi¬ 
mal die letzte Stelle um +-1 falsch ist. Bei 
Addition des maximalen Fehlers ergeben sich 
so sechs unsichere Stellen. Bei Berücksichti¬ 
gung der anderen zwei arctan-Terme ist man 
ebenfalls mit sechs unsicheren Stellen auf 
jeden Fall auf der sicheren Seite. 

Bei der Berechnung von Pi mit 100000 Nach¬ 
kommastellen stimmt (im Vergleich zu Pi mit 
250000 Stellen) sogar noch die letzte Stelle, 
da intern ein paar Byte mehr reserviert wer¬ 
den, als zur Darstellung der Dezimalzahl 
nötig. Zum Vergleich sind auf der Diskette 
zum Heft die Ergebnisse von »Pi 100000« 
und »Pi 250000« als Text gespeichert. 
Ausführungszeit: Die Ausführungszeit wurde 
auf einem normalen Amiga 500 (7.14 Mhz) 
gemessen, (vom Start des Programms, bis zur 
Beendigung der Bildschirmausgabe). Die fol¬ 
gende Tabelle zeigt die Ergebnisse. Versu¬ 
chen Sie, das Programm doch entsprechend 
auszubauen und zu verbessern, daß es noch 
schneller wird. Viel Erfolg. ub 


Anzahl Nachkommastellen benötigte Zeit 

1000 

6 sec 

10000 

8 min 52 sec 

100000 

14 Stunden 48 min 49 sec 

250000 

4 Tage 23 Stunden 44 min 16 sec 

1 Million 

79 Tage 19 Stunden (geschätzt) 
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Faszination Programmieren Nr. 1 











1: * Pi, mit 

max. 1000000 Nachkommastellen * 

2: * Pi=48*arctan (l/18)+32*arctan (1/57)-20*a 

rctan (1/239) * 

3: * (Berechnung acrtan mit Taylorpolynom) * 

4: * von HEIKO HIRSCHMÜLLER * 

5: * Computer : Amiga 500, Kickstart 2.0 * 

6: * Assembler : Devpac V 2.0 * 

7: Lenght 

equ 4096 * Länge Ausgabepuffer 

8: ExecBase equ 4 * Libraryfunktionen 

9: AllocMem equ -198 

10: FreeMem 

equ -210 

11: OpenLib 

equ -552 

12: CloseLib equ -414 

13: Output 

equ -60 

14: Write 

equ -48 

15: * Anzahl der Nachkommastellen lesen 

16: moveq 

#0,dO * Anzahl der gewünschten 

17: moveq 

#0,dl * Nachkommastellen aus 

18: move.w 

#48,d2 * Kommandozeile lesen und 

19: NextZiff move.l d0,d3 * in binäre Zahl wand 

ein 


20: lsl.l 

#2,d3 

21: add.l 

d3,d0 

22: add.l 

d0,d0 

23: add.l 

dl,dO 

24: move.b 

(aO)+,dl 

25: sub.b 

d2,dl 

26: blt 

Vergl * list, bis keine 

27: cmp.b 

#9,dl * Ziffern mehr vorhanden 

28: bis 

NextZiff 

29: Vergl 

cmp.l #12,d0 * Anzahl zwischen 

30: bhi 

groesser * 12 und 1000000 

31: moveq 

#12,dO 

32: groesser cmp.l #1000000,dO 

33: bis 

kleiner 

34: move.l 

#1000000,dO 

35: kleiner 

and.b #$fc,d0 * durch 4 teilbar 

36: move.l 

d0,DezLen * berechnete Zahl sichern 

37: * Länge des benötigten Speichers berechnen 

38: move.l 

d0,dl * Länge in Bytes := 

39: swap 

dl * (Anz. Dez. Stellen)*4152 

40: mulu 

#1038,dl * /10000+8 

41: swap 

dl 

42: mulu 

#1038,dO 

43: add.l 

dl,dO 

44: moveq 

#0,dl 

45: swap 

dO 

46: move.w 

dO,dl 

47: divu 

#10000,dl 

48: swap 

dl 

49: move.w 

dl.dO 

50: swap 

dO 

51: divu 

#10000,dO 

52: move.w 

d0,dl 

53: lsl.l 

#2,dl 

54: add.l 

#8, dl 

55: move.l 

dl,laenge * und sichern 

56: * Dos-Library öffnen, Output-Handle holen 

57: lea 

dosname(pc),al * Dos-Lib. öffnen 

58: moveq 

#0,d0 

59: move.l 

ExecBase,a6 

60: jsr 

OpenLib(a6) 

61: tst.l 

dO 

62: beq 

ende 

63: move.l 

dO,dosbase 

64: move.l 

d0,a6 * Output-Handle 

65: jsr 

Output(a6) * holen 

66: move.l 

dO,handle 

67: * benötigten Speicher reservieren 

68: moveq 

#2,d7 * Speicher für 

69: lea 

Summand(pc),a5 * Summanden, Zwischen 

70: reserv move.l laenge(pc),d0 * Summe reserv. 

71: moveq 

#l,dl 

72: swap 

dl 

73: move.l 

ExecBase,a6 

74: jsr 

AllocMem(a6) 

75: move.l 

al,(a5) + 

76: tst.l 

dO 

77: beq 

abbruch 

78: dbra 

d7,reserv 

79: * Startwerte des 1. Summanden von arctan 

80: lea 

Startwert(pc),a3 * ->Startwerte 

81: moveq 

#2,d3 * 3 Terme berechnen 

82: Do move.l Summand(pc),a5 * -> Summand 

83: move.l 

laenge(pc),d5 * Länge in Worten 

84: lsr.l 

d5 

85: move.w 

(a3)+,(a5) * Multipl.-> Summand 

86: move.w 

(a3),d6 * Divisior 

87: move.l 

d5,d4 * Summand : = 

88: subq.l 

#l,d4 * Summand/Divisor 

89: swap 

d4 

90: move.l 

a5,al 

91: moveq 

#0,d0 

92: Dividl 

swap d4 

93: Divid2 

move.w (al),d0 

94: divu 

d6,d0 


135 

bgt 

Taylor 


136 

adda.l 

#2,a3 * Für alle 3 Terme die 

137 

dbra 

d3,Do * gleiche Prozedur 

138 

* Ergebnis in Dez. Zahl wandeln und ausgeben 

139 

move.l Summe(pc),a4 * 

Ziffer in 1. Wort von 

140 

move.l 

laenge(pc),d7 

* Summe und ein 


Komma 



141 

lea 

Ausgabe(pc),a5 * in Ausgabepuffer 

142 

move.w 

#$2020,dO 

* schreiben. 

143 

swap 

dO 


144 

move.w 

(a4),d0 


145 

add.w 

#48,dO 


146 

lsl.w 

#8,d0 


147 

move.b 

#'.',d0 


148 

move.l 

dO,(a5)+ 


149 

move.l 

#Lenght/4-2,d3 * restl. Länge in d3 

150 

move.w 

#0,(a4) 


151 

add.l 

d7,a4 

Ende von Summe -> a4 

152 

lsr.l 

#l,d7 * 

Länge von Summe 

153 

subq.l 

#l,d7 * 

in Worten 

154 

move.l 

DezLen(Dc),d5 

* Anz. der 

155 

lsr.l 

#2,d5 

* Dezimalstellen/4 

156 

red 

move.l a4,a0 

* Startwerte der 

157 

move.l 

d7,d6 

Reduktionsschleife 

158 

swap 

d6 


159 

move.w 

#10000,d4 


160 

moveq 

#0, dl 


161 

redl swap d6 * Summe mit 10000 

162 

red2 move.w -(a0),d0 

‘multiplizieren 

163 

mulu 

d4,d0 

* und ... 

164 

add.l 

dl,d0 


165 

move.w 

dO,(aO) 


166 

swap 

dO 


167 

move.w 

d0,dl 


168 

dbra 

d6,red2 


169 

swap 

d6 


170 

dbra 

d6,redl 


171 

move.w 

dO, (aO) 

... Übertrag 

172 

swap 

dO 

ausgeben 

173 

jsr 

print(pc) 


174 

subq.l 

#l,d5 


175 

bgt 

red * und nochmal 


95 

move.w 

dO,(al)+ 

96 

dbra 

d4,Divid2 

97 

swap 

d4 

98 

dbra 

d4, Dividl 

99 

move.l 

d5,d4 * Summe:= 

100 

lsr.l 

d4 * Summe Summand 

101 

subq.l 

#l,d4 

102 

swap 

d4 

103 

move.l 

Summe(pc),a0 

104 

add.l 

d5,a0 

105 

add.l 

d5,a0 

106 

tst.w 

2(a3) * + oder - wird fest- 

107 

blt 

SubLoopl * gelegt bei Start- 

108 

SumLoopl swap d4 * werten. 

109 

SumLoop2 addx.l -(al),-(a0) 

110 

dbra 

d4, SumLoop2 

111 

swap 

d4 

112 

dbra 

d4,SumLoopl 

113 

bra 

LoopEnd 

114 

SubLoopl swap d4 

115 

SubLoop2 subx.l -(al),-(aO) 

116 

dbra 

d4,SubLoop2 

117 

swap 

d4 

118 

dbra 

d4,SubLoopl 

119 

LoopEnd 


120 

* Berechnung des folgenden Summanden des 

121 

* Taylorpolynoms und Addition zur Summe 

122 

mulu 

(a3)+,d6 * Divisor ist quadratisch 

123 

moveq 

#3,d7 * Startwert des Zählers i 

124 

move.l 

Zwischen(pc),a4 

125 

Taylor 

jsr div(pc) 

126 

* Summand:=Summand/Divisor - Zwischen:=Sum 


mand/i 


127 

jsr 

wischen 

summiere(pc) * Summe:=Summe +,- Z 

128 

addq.l 

#2,d7 * i:=i+2 

129 

tst.l 

(a5) * Wenn die ersten Ziffern 

130 

bne 

Taylor * des Summanden null sind, 

131 

moveq 

#4,d0 

132 

adda.1 

d0,a5 * dann können diese über- 

133 

adda.l 

d0,a4 * Sprüngen werden. 

134 

subq.l 

#2,d5 
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176 

jsr 

Out(pc) * Rest Ausgabepuffer 

233 

move.w 

d3,d2 * und beides in a2 

292 

rts 

177 

move.l 

#$2e2e2e0a,Ausgabe 

234 

move.l 

d2,a2 * sichern 

293 

subtr sub dO,dO * x-Flag loeschen 

178 

move.w 

#Lenght/4-2,d3 * '...' und CR 

235 

loop21 swap d4 * Eigentliche 

294 

subtrl swap d4 

179 

jsr 

Out(pc) * ausgeben. 

236 

loop22 move.w (al),dO * Divisionsschleife 

295 

subtr2 subx.l -(aO),-(al) * Summe-Summand 

180 

* Speicher freigeben und Dos-Lib. schließen 

237 

divu 

d6,d0 * erste Division wie oben 

296 

dbra d4,subtr2 

181 

lea 

Zwischen+4(pc),a5 

238 

move.w 

dO,(al)+ 

297 

swap d4 

182 

rroveq 

#l,d7 

239 

move.l 

dl,d2 * Faktor abschätzen, 

298 

dbra d4,subtrl 

183 

neg.w 

d7 

240 

move.l 

a2,d3 * durch dividieren 

299 

rts 

184 

abbruch 

cmp.w #2,d7 

241 

divu 

d3,d2 * mit vermindertem 

300 

* Ausgabe eines Wortes in dO (d0<10000) als 

185 

beq 

ende 

242 

move.w 

d2,d5 * 16 Bit Nenner 


Dezimalzahl 

186 

move.l 

-05),al 

243 

swap 

d5 

301 

print moveq #3,dl * 4 Ziffern 

187 

move.l 

laenge(pc),d0 

244 

move.w 

d0,d2 

302 

moveq #'0',d2 * Ascii-Code von ’0' 

188 

move.l 

Exec3ase,a6 

245 

divu 

d3,d2 

303 

moveq #10, d4 * Divisor 

189 

jsr 

FreeMem(a6) 

246 

move.w 

d2,d5 

304 

adda.l #4,a5 

190 

addq.w 

#l,d7 

247 

swap 

d3 * und zusätzlich 

305 

Ziffer divu d4,d0 * Ziffer abspalten 

191 

bra 

abbruch 

248 

lsr.l 

d3,d5 * verschieben 

306 

swap dO 

192 

move.l 

dosbase(pc),al 

249 

move.l 

d7,d3 

307 

add.w d2,d0 * in Ascii-Code wandeln 

193 

move.l 

ExecBase,a6 

250 

swap 

d3 

308 

move.b d0,-(a5) * in Puffer schreiben 

194 

jsr 

CloseLib(a6) 

251 

mulu 

d5,d3 * echtes i mit 

309 

move.w #0,d0 

195 

ende 

moveq #0,d0 

252 

move.w 

d7,d2 * abgeschätztem Faktor 

310 

swap dO 

196 

rts 

endlich fertig !!! 

253 

mulu 

d5,d2 * multiplizieren 

311 

dbra dl»Ziffer * das Ganze 4 mal 

197 

* Berechnung eines Summanden der Taylorreih 

254 

sub.w 

d2,d0 

312 

adda.l #4,a5 * Zeiger erhöhen 


e von arctan 

255 

move.w 

#0,d2 

313 

dbra d3,NotOut * Wenn voll, dann... 

198 

* (Summand=a5, Zwischensp.=a4, länge=d5, Ne 

256 

swap 

d2 

314 

Out move.l handle(pc),dl * Puffer ausgeben 


nner=d6, 

i=d7) 

257 

addx.l 

d2,d3 * und vom Ausgangswert 

315 

lea Ausgabe(pc),a5 * Pufferanfang 

199 

div move.l d5,d4 * Länge in Worten-1 

258 

sub.l 

d3,dl * abziehen. 

316 

move.l a5,d2 

200 

subq.l 

#l,d4 * nach d4 

259 

swap 

dl * Rest volständig nach 

317 

ext.l d3 * Pufferlänge berechnen 

201 

swap 

d4 

260 

move.w 

dO,dl * dl schreiben. 

318 

lsl.l #2,d3 

202 

move.l 

a5,al * Zeiger auf Summanden 

261 

Korr cmp.l d7,dl * eventuell das ganze 

319 

sub.l #Lenght-4,d3 

203 

move.1 

a4,a0 * Zeiger auf Zwischensp. 

262 

blt 

NoKorr * noch korregieren 

320 

neg.l d3 

204 

moveq 

#0,d0 

263 

addq.l 

#l,d5 * (Rest befindet sich 

321 

move.l dosbase(pc),a6 

205 

moveq 

10, dl 

264 

sub.l 

d7,dl * in dl (long !) und 

322 

jsr Write(a6) 

206 

cmp.l 

#65535,d7 

265 

bra 

Korr * Faktor in d5 (wort !)) 

323 

move.l #Lenght/4-l,d3 

207 

bhi 

div2 

266 

NoKorr move.w d5,(a0)+ * Faktor -> Zwischen. 

324 

NotOut rts * ... sonst nicht 

208 

loopl 

swap d4 

267 

dbra 

d4,loop22 



209 

loop2 

move.w (al),dO * Wort holen 

268 

swap 

d4 

325: 

: *-Datenteil- 

210 

divu 

d6,d0 * durch d6 teilen 

269 

dbra 

d4,loop21 



211 

move.w 

d0,(al)+ * und zurückschreiben 

270 

movem.l 

(sp)+,d3/d5 * Register hersteilen 

326: 

: dosbase dc.l 0 

212 

move.w 

dO,dl * denn gleichen Wert 

271 

rts 

* Division beendet 

327: 

: handle dc.l 0 

213 

divu 

d7,dl * durch d7 (=i) teilen 

272 

* Summand zum Ergebnis addieren 



214 

move.w 

dl,(aO)+ * und in Zwischensp. 

273 

* (a3 Zeiger auf Flag, (Add. bzw. Subtr.)) 

328: dosname dc.b ’dos.library',0 

215 

dbra 

d4,loop2 * doppelte Schleife, da 

274 

summiere move.1 laenge(pc),d4 • 

329 

* Startwerte: Multiplikator, 1/Argument, Flag 

216 

swao 

d4 * dbra nur mit 16-Bit 

275 

move.1 

Zwischen(pc),aö * Zeiger auf Ende 

330 

Startwert dc.w 48,18,1 * 48*arctan (1/18) 

217 

dbra 

d4,loopl * Zählern arbeitet 

276 

adda.l 

d4,a0 * Zwischenspeicher 

331 

dc.w 32,57,1 * 32*arctan (1/57) 

218 

rts 


277 

move.1 

Summe(pc),al * Zeiger auf Ende 

332 

dc.w 20,239,-1 * -20*arctan (1/239) 

219 

div2 movem.l d3/d5,-(sp) * Wenn i>65535, 

278 

adda.l 

d4,al * Summe 

333 

DezLen dc.l 0 * Anzahl der Stellen 

220 

moveq 

#15,d2 * muß umständlicher und 

279 

lsr.l 

#2,d4 * Laenge in 

334 

laenge dc.l 0 * Länge in Bytes 

221 

swap 

d7 * zeitaufwendiger Divid. 

280 

subq.l 

#i,d4 * Langworten - 1 

335 

* Komma, nach 1. Wort 

222 

Check 

btst.l d2,d7 * werden. 

281 

swap 

d4 

336 

Summand dc.l 0 * Zeiger auf jeweiligen 

223 

dbne 

d2,Check * Nenner für erste 

282 

move.w 

(a3),d0 

337 

Summe dc.l 0 * Speicherbereich 

224 

swap 

d7 * Schätzung auf 16 Bit 

283 

eor.w 

d7,d0 

338 

Zwischen dc.l 0 

225 

addq.w 

#l,d2 * vermindern. 

284 

btst 

#l,dO * jeder 2. Summanden 

339: Ausgabe ds.b Lenght * Ausgabepuffer 

226 

move.l 

d7,d3 

285 

bne 

subtr * muß subtr. werden 



227 

lsr.l 

d2,d3 

286 

sub 

dO,dO * x-Flag loeschen 


© 1993 M&T 

228 

addq.w 

#l,d3 * Verminderten Nenner 

287 

addil swap d4 



229 

bcc 

Ok * etwas größer wählen, 

288 

addi2 addx.l -(aO),-(al) * Summe+Summand 



230 

231 

move.w 

addq.w 

#$8000,d3 * damit der gesuchte 
#l,d2 * Faktor eher zu 

289 

290 

dbra 

swap 

d4,addi2 

d4 

»Pi.asm«:Ein schnelles Programm, um 

232 

Ok swap 

d2 * klein wird 

291 

dbra 

d4,addil 

Pi möglichst genau zu berechnen 
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PROGRAMMIERSPRACHEN 


Programmierkurs Oberon 

Auf Wirth'sehen Spuren 


Oberon, eine Programmierspra¬ 
che aus dem Wirth'sehen Hause, 
faßt auf dem Amiga langsam aber 
sicher Fuß. Wo liegen die Stärken 
der Sprache? Wir bringen Ihnen 
Oberon in einem umfassenden 
Ein-/Aufsteigerkurs näher. 

von Kai Bolay 

A miga-Oberon ist ein interessanter 
Compiler dank seines mächtigen 
Sprachkonzepts. Die Ideen von 
Modula-2 wurden weiterentwickelt und 
erweitert [1]. Einige weniger gebräuchliche, 
hinderliche oder auch für den Compiler- 
Bauer aufwendige Features entfielen. 

Um die in diesem Kurs besprochenen Pro¬ 
gramme und theoretischen Grundlagen in die 
Praxis umzusetzen, sollten Sie den Amiga- 
Oberon-Compiler der A+L AG besitzen [2]. 
Aber auch mit der Demo-Version [3] lassen 
sich die ersten Schritte nachvollziehen. Sehr 
empfehlenswert ist der Source-Level-Debug- 
ger. Mit ihm lassen sich alle Programme 
Schritt für Schritt nachvollziehen. 

Die Demo-Version des Amiga-Oberon- 
Compilers finden Sie auf unserer Diskette 
zum Heft (Seite 114) oder auf der AMOK- 
PD-Diskette 53 [3]. Ab Nummer 36 finden 
Sie auf der AMOK-Serie weitere Oberon- 
Programme, die die Leistungsfähigkeit von 
Amiga-Oberon dokumentieren. Sie eignen 
sich insbesondere, die Sprache besser auszu¬ 
nutzen und kennenzulernen. 

Eleganter Einstieg 

Am besten lernt man eine Sprache, indem 
man sie spricht. So paradox das klingen mag, 
gilt es auch für Programmiersprachen. Ein 
beliebtes erstes Programm ist »Hello World«. 
Sein Aufbau ermöglicht es, das Konzept, die 
Struktur und Funktionsweise einer Program¬ 
miersprache relativ einfach nachzuvollzie¬ 
hen. Listing 1 demonstriert es. 

Jedes Programm bzw. Modul beginnt mit 
dem Schlüsselwort »MODULE«, gefolgt von 
dem Programmnamen. Dieser darf keine 
Umlaute bzw. Sonderzeichen enthalten und 
muß mit einem Buchstaben beginnen. Glei¬ 
ches gilt bei Oberon auch für Variablen-, 
Typen- und Konstantennamen. Nach dem 
obligatorischen Semikolon (u.a. auch von C- 
Programmen bekannt) folgt oft die Importli¬ 
ste. Im Unterschied zu Modula-2 [1] kann 
nur unqualifiziert importiert werden - es las¬ 
sen sich somit nur ganze Module importieren. 
Im fertigen Programm landen dann aber. 


dank optimierendem Linken, nur die wirklich 
benötigten Modul-Funktionen. 

Was ist ein Modul? Jedes Programm in 
Oberon ist ein Modul. Unser Hello-World- 
Programm ist auch eins. Erst durch das Lin¬ 
ken (Binden) wird es zum Programm. In 
Modulen faßt man logisch zueinander pas¬ 
sende Teile eines Programms zusammen. Wir 
werden später noch ausführlicher auf dieses 
Thema eingehen. Da Bildschirmausgaben 
nicht zum Sprachkem Oberons gehören, muß 
man sie selbst programmieren. Doch diese 
Arbeit wurde schon erledigt. Auf der Compi¬ 
ler-Diskette befindet sich das fertige Modul 
»io«, das Ein- und Ausgaben auf den Bild¬ 
schirm regelt. 

Mit Hilfe des Schlüsselworts »IMPORT« 
werden die Funktionen anderer schon vor¬ 
handener Module zugänglich. Die Importliste 
besteht aus Modulnamen, getrennt durch 
Kommata, die ihrerseits wiederum durch ein 
Semikolon abgeschlossen werden. In unse¬ 
rem Beispiel wird nur ein Modul importiert. 

Anschließend beginnt unser kurzes Pro¬ 
gramm. Dem Compiler wird dies mit dem 
Wort »BEGIN« angezeigt. Nun rufen wir die 
Prozedur »io.WriteString« eines anderen 
Moduls auf. Eine Prozedur ist ein Unterpro¬ 
gramm und kennzeichnet sog. imperative 
Programmiersprachen. Eine Prozedur läßt 
sich von mehreren Programmteilen aufrufen 
und erlaubt die Zerlegung großer Programme 
in kleine überschaubare Teile. 


Woran erkennt nun der Compiler, aus wel¬ 
chem Modul die Prozedur stammt? Wir müs¬ 
sen es ihm kenntlich machen. Im allgemeinen 
geschieht dies durch Voranstellen des 
Modulnamens, also »Modulname.Prozedur«. 
In unserem Beispiel demzufolge »io.Wri¬ 
teString«. Ruft man eigene Prozeduren inner¬ 
halb eines Moduls/Programms auf, entfällt 
selbstverständlich die Angabe des Modulna¬ 
mens. Auf die Programmierung eigener Pro¬ 
zeduren gehen wir noch ein. 

Die in dem Beispielprogramm verwendete 
Prozedur WriteString dient einzig dem 
Zweck, eine Zeichenkette auf dem Bild¬ 
schirm auszugeben. Diese müssen wir als 
Parameter übergeben. Ein Parameter ist sozu¬ 
sagen die Eingabe einer Prozedur. Hierüber 
teilt man ihr mit, welche Daten zu verwenden 
sind. In Oberon werden die Parameter nach 
dem Prozedurnamen in Klammern (»(« und 
»)«) angegeben. Mehrere Parameter trennen 
wir durch Kommata. io.WriteString benötigt 
nur einen. Es ist die Zeichenkette, die auszu¬ 
geben ist; Oberon erwartet sie in Anfüh¬ 
rungszeichen. Im Beispiel geben wir zu¬ 
sätzlich die Zeichenfolge »\n« an, was nichts 
anderes als einen Zeilenvorschub bedeutet. 
Nach der schließenden Klammer folgt wieder 
ein Semikolon. Neben dem »\n« gibt's noch 
mehr Steuerzeichen. Diese finden Sie in 
unserem Kasten. 

Hiermit ist das Programm beendet. Oder 
doch nicht? Wir wissen schon, daß eine Pro- 


Amiga-Oberon 


Die Umsetzung von Oberon auf den Amiga 
wurde von Fridtjof Sieben vorgenommen. 
Oberon umfaßt bereits einen Garbage-Collector 
(Abfall-Sammler), um Programmierer von der 
mitunter diffizilen Aufgabe, dynamisch allozier- 
ten Speicher freizugeben, wirksam zu entlasten. 
Garbage-Collection ist eigentlich eine Aufgabe 
des Betriebssystems. 

Nach Jahren praktischer Erfahrung mit Oberon 
und einer unveröffentlichten objektorientierten 
Erweiterung entstand 1991 Oberon-2 als univer¬ 
sell verwendbare Sprache, die das Konzept von 
Modula-2 und Oberon fortführte. Das Sprach- 
konzept wurde im wesentlichen um typgebun¬ 
dene Prozeduren erweitert, die in anderen objekt¬ 
orientierten Sprachen als Methoden bezeichnet 
werden. Oberon-2 ist eine vollwertige objektori¬ 
entierte Sprache mit den wesentlichen Konzepten 
der Datenabstraktion durch Klassenbildung, der 
Polymorphie und Vererbung durch Typerweite¬ 
rung und der dynamischen Bindung von Metho¬ 
den zur Laufzeit. Trotz der Bereicherungen liegt 
Oberon-2 ein frappierend einfaches und leicht 
verständliches Konzept zu Grunde. 


Bei Amiga-Oberon ist der Editor als eine um¬ 
fassende, frei programmierbare Entwicklungsum¬ 
gebung ausgelegt. Alles läßt sich von hier aus 
perfekt steuern. Der Compiler erzeugt rasant sehr 
schnellen und hochgradig optimierten Code im 
Standardformat, auf Wunsch auch für höhere Pro¬ 
zessoren. Jeder für die Codegenerierung nur 
denkbare Sonderfall kann durch Optionen be¬ 
rücksichtigt werden. Der Garbage-Collector (neu 
in Version 3.0) verrichtet dank Multitasking seine 
Arbeit im Hintergrund, ohne das System spürbar 
zu belasten. Natürlich kostet Garbage-Collection 
CPU-Zeit. Ein Zusatzprodukt ist der interaktive 
Debugger, der auf Quelltextebene arbeitet und bei 
Bedarf Programme schrittweise ausführt. Die 
maschinennahen Sprachelemente und die Mög¬ 
lichkeit, Maschinencode als INLINE-Statement 
einzufügen, bieten gute Voraussetzungen für die 
Systemprogrammierung. 

Bezugsquelle: A+L AG. Däderiz 61. CH-2540 Grenchen, Tel.. 

00 41 (65) 52 03 11. Fax 00 41 (65) 52 03 79 

Preis: Oberon 3.0-Compilen ca. 350 Mark, Source-Level-Debug- 
ger: ca. 230 Mark 
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zedur bzw. Blöcke mit dem Schlüsselwort 
BEGIN eingeleitet werden. Fehlt da nicht 
was? Klar, das Gegenstück - es heißt 
»END«. Hier lernen wir eine wichtige Struk¬ 
tur sogenannter Hochsprachen kennen: das 
Blockkonzept. Ein Block ist eine in sich 
abgeschlossene Programmeinheit und wird 
durch entsprechende Symbole verpackt. In 
Pascal bzw. Oberon sind es BEGIN und 
END, in C z.B. die geschweiften Klammem 
»{« bzw. »}«. Doch keine Regel ohne Aus¬ 
nahme: Das Ende eines Moduls muß zusätz¬ 
lich mit einem Punkt versehen sein, also 
»END.«. 

Starten Sie jetzt den Editor »OEd« Ihres 
Oberon-Compilers oder der Oberon-Demo 
und tippen Sie Listing 1 ab (ohne die am Zei¬ 
lenanfang abgedruckten Zeilennummern; sie 
dienen lediglich der Orientierung). Um das 
Programm zu starten, sind zwei Schritte 
nötig: Das Kompilieren und Binden. Wählen 
Sie aus dem OEd-Menü den Menüpunkt 
»Execute« aus. Der Compiler wird gestartet 
und überprüft den eingegebenen Quelltext 
auf Tipp- oder sonstige Fehler. Erkennt der 
Compiler einen, meldet er dies, indem der 


1: MODULE HelloWorld; 

2: IMPORT 
3: io; 

4: BEGIN 

5: io.WriteString ("Hello World!\n"); 

6 : END HelloWorld. © 1993 M&T 

Listing 1: HelloWorld.mod gibt 
ebendiesen simplen Text aus - 
»Hello World« 


Cursor auf die entsprechende Position im 
Quelltext gesetzt wird und eine adäquate 
Fehlermeldung erscheint. Verlief hingegen 
das Kompilieren erfolgreich, aktiviert OEd 
selbständig den Linker »OLink« und bindet 
das Programm mit den notwendigen Modu¬ 
len, u.a. dem von uns importierten io-Modul. 
Anschließend führt OEd das Programm aus. 
Diese Schritte sind auch »zu Fuß« abrufbar. 
Verwenden Sie hierzu die Menüpunkte 
»Compile« und »Link«. 

Nachdem wir nun kurz in Oberon hinein¬ 
geschnuppert haben, widmen wir uns der 
Theorie. Hauptaufgabe eines Programms ist 
die Datenbearbeitung. Zuvor allerdings sind 
diese zunächst einmal einzurichten. Daten, 
die immer den gleichen Wert besitzen und 
sich auch während der Laufzeit eines Pro¬ 
gramms ändern, bezeichnet man als Konstan¬ 
ten. Einer Konstanten gibt man einen Namen. 
Variablen-, Konstanten-, Prozedurnamen etc. 
müssen einer bestimmten Definition genü¬ 
gen: Am Anfang steht immer ein Buchstabe 
oder der Unterstrich »_«. Nun dürfen Buch¬ 
staben, Zahlen oder weitere Unterstriche fol¬ 
gen. Wichtiger als Konstanten sind zumeist 
Variablen. Darunter versteht man Platzhalter 
bzw. Speicherplätze, die ihren Wert ändern 
können. Es gibt verschiedene Variabien- 
Typen (s. Kasten). 

Die Zahlen-Typen »SHORTINT« bis 
»LONGREAL« lassen sich leicht ineinander 
umwandeln. Rechnet man gemischt, also 


sowohl mit der einen als auch anderen, 
besitzt das Ergebnis immer den größten vor¬ 
kommenden Typ. Multiplizieren wir eine 
Integer-Zahl mit einer LongReal-Zahl, ist das 
Ergebnis eine LongReal-Zahl. Doch ein Typ 
läßt sich auch explizit »verkleinern«. Mit 
»SHORT« degradiert man eine Real- zu einer 
Longlnt-Zahl. In der Praxis werden Sie diese 
Möglichkeit schätzen lernen. 

Das Programm »Kreis.mod« (Listing 2) 
demonstriert die Verwendung von Variablen 
und Konstanten. Zugleich lernen wir Kom¬ 
mentare kennen. Kommentare dienen aus¬ 
schließlich der Dokumentation und Lesbar¬ 
keit von Programmroutinen und werden vom 
Compiler überlesen. Kommentare müssen in 
Oberon mit den Zeichenfolgen »(*« und »*)« 
eingeschlossen werden. 

Wie gewohnt beginnt das Programm mit 
dem Modulkopf und den entsprechenden 
Importen. Doch bei den Importen versteckt 
sich etwas Neues. Wir importieren zwei 
Module, »io« und »ReallnOut«. »rio:« 
bedeutet, daß man anstatt »ReallnOut.« auch 
»rio.« schreiben kann, wenn man sich auf 
dieses Modul bezieht. Diese Abkürzungs¬ 
möglichkeit ist sehr praktisch (man denke an 
Module mit der abenteuerlichen Schreib¬ 
weise »LongRealConversions«; der Fehler¬ 
teufel läßt grüßen). 

Anschließend legen wir die Konstante »Pi« 
fest. Die Konstantendeklaration wird mit dem 
Schlüsselwort »CONST« eingeleitet. Vor 
dem Gleichheitszeichen steht der Name der 
Konstante, danach ihr Wert. Und wieder das 
obligatorische Semikolon. Weiterhin definie¬ 
ren wir die beiden Konstanten »Vorkomma« 
und »Nachkomma«. Für das Programm 
benötigen wir zudem drei Variablen. Wir 
nennen sie treffenderweise »Radius«, 
»Umfang« und »Flaeche«. Alle sind vom 
Typ »REAL«, da in diesen Variablen Dezi¬ 
malbrüche gespeichert werden. Im übrigen ist 
es unbedingt empfehlenswert, Variablenna¬ 
men so zu bezeichnen, daß ihre Funktion 
schon aus dem Namen ersichtlich ist (das gilt 
aber nicht unbedingt für kurzlebige Schlei¬ 
fenvariablen). 


Nun könnte man auf die Idee kommen, 
ausschließlich Variablen vom Typ »LONG¬ 
REAL« zu verwenden. Schließlich ist es 
möglich, in LongReal-Zahlen den Inhalt aller 
anderen Variablentypen aufzunehmen. Der 
Schluß ist durchaus richtig, aber kaum prakti¬ 
kabel. Berechnungen mit Fließkommazahlen 
sind viel langsamer als vergleichbare Opera¬ 
tionen mit z.B. Ganzzahlen. Benötigt man 


Steuerzeichen 

\n 

neue Zeile 

\f 

Bildschirm löschen/neue Seite 

\t 

Tabulator 

\b 

letztes Zeichen löschen 

\r 

an den Anfang der Zeile springen 

\o 

Stringende-Zeichen 

\\ 

Der Backslash (\) 

V 

einfaches Anführungszeichen (') 

V 

doppeltes Anführungszeichen (") 

\NNN 

Das Zeichen mit der Octalzahl NNN 

\xNN 

Das Zeichen mit der Hexzahl NN 

\[ 

Der CSI-Code ("\x3F") 

\ 

Zeilenende im Quelltext überlesen 


nur ganze Zahlen, sollte unbedingt auf einen 
»INTEGER«-Typ ausgewichen werden - er 
ist einfach schneller. Da unser Programm 
allerdings Fließkommazahlen benötigt, bleibt 
uns in diesem Fall nichts anderes übrig, als 
den Real-Typ zu bemühen. 

Nach dem schon bekannten io.WriteString 
folgt das Einlesen des Radius. Dies geschieht 
mit Hilfe der Prozedur »ReadReal«, die, wie 
man am vorangestellten »rio.« erkennt, aus 
dem Modul»RealInOut« importiert wird. Der 
Parameter dieser Prozedur ist die Variable, in 
der der eingelesene Wert abzulegen ist. 
Beachten Sie die Schlüsselwörter »IF« und 
»THEN END« noch nicht. Wir kommen dar¬ 
auf zurück. Es folgt die Wertzuweisung der 
restlichen Variablen. Eine Zuweisung kenn¬ 
zeichnet man in Oberon mit der Symbolfolge 
»:=«. Hier wird der linken Seite der Wert der 
rechten zugewiesen. Dabei darf es sich um 
Zahlen, Ausdrücke oder ähnliches handeln. 

Für die Ergebnisausgabe werden die Pro¬ 
zeduren WriteString und »WriteReal« ver- 


l 

MODULE Kreis; (* Umfang und Flächeninhalt *) 


2 

IMPORT 


3 

io, rio: ReallnOut; 


4 

CONST 


5 

Pi = 3.1415926536; {* Die magische Konstante *) 


6 

Vorkomma = 5; 


7 

Nachkomma = 2; 


8 

VAR 


9 

(* Die Variablen *) 


10 

Radius, Umfang, Flaeche: REAL; 


11 

BEGIN 


12 

{* Vorbereitung *) 


13 

io.WriteString 


14 

("Bitte geben sie den Radius des Kreises ein: "); 


15 

IF rio.ReadReal (Radius) THEN END; (* Radius einiesen *) 


16 

(* Berechnung ... *) 


17 

Umfang := 2 * Pi * Radius; 


18 

Flaeche := Pi * Radius * Radius; 


19 

(* Ausgabe *) 


20 

io.WriteString ("Der Umfang beträgt: •); 


21 

IF rio.WriteReal (Umfang, Vorkomma, Nachkomma, FALSE) 

Listing 2: Kreis.mod 

22 

THEN END; 

23 

24 

io.WriteLn; 

io.WriteString ("Die Fläche ist: "); 

berechnet den Umfang 

25 

IF rio.WriteReal (Flaeche, Vorkomma, Nachkomma, FALSE) 

und die Fläche eines 

26 

27 

THEN END; 
io.WriteLn; 

Kreises nach Eingabe 

28 

END Kreis. © 1993 m&t 
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wendet. WriteReal benötigt vier Parameter. 
Der erste ist die REAL-Zahl, die auszugeben 
ist. Die nächsten beiden Parameter bestim¬ 
men die Anzahl der Vor- und Nachkomma¬ 
stellen. Ob wissenschaftliche Darstellung 
gewünscht ist, gibt der letzte Parameter an. 
»FALSE« steht für normale Darstellung, 
»TRUE« für die Darstellung mit Zehnerpo¬ 
tenzen. Und schon haben wir zwei weitere 
Oberon-Schlüsselwörter kennengelemt: 
FALSE und TRUE. Sie repräsentieren im 
Prinzip nur zwei Zahlen: 0 bzw. 1. TRUE 
verwenden wir immer, wenn eine Bedingung 
richtig ist. 

Auch hier sollten Sie zunächst das »IF« 
und »THEN END« wiederum nicht beachten. 
»WriteLn« bewirkt dasselbe wie »io.Wri- 
teString ("\n")«, einen einfachen Zeilenvor¬ 
schub. 

Bedingungen, Schleifen 
und Fallunterscheidungen 

Bis jetzt liefen alle Programme von oben 
nach unten durch. Es gab keine Möglichkeit, 
Teile des Programms bei bestimmten Bedin¬ 
gungen nicht auszuführen. Dies ändert sich 
mit der »IF«-Abfrage. Schauen Sie sich 
hierzu Listing 3, »Meinung.mod«, an. Wie¬ 
derum importieren wir das Modul io. Außer¬ 
dem vereinbaren wir eine Ganzzahlvariable 
mit dem Namen »Eingabe« und geben einen 
Text auf dem Bildschirm aus. Dann folgt die 
erste »IF«-Bedingung. Die Prozedur »Read- 
Int« hat einen Rückgabewert. Sie teilt uns 
mit, ob eine Zahl eingelesen werden konnte. 
Ebendies läßt sich mit dem IF-Kommando 
abfragen. Liefert Readlnt TRUE, hat alles 
geklappt. Anschließend werden alle Zeilen 
bis zur ELSE-Anweisung ausgeführt. Schickt 
Readlnt hingegen FALSE zurück, werden die 
zwischen ELSE und END stehenden Pro¬ 
grammzeilen abgearbeitet. Der ELSE-Teil ist 
nicht zwingend notwendig. Trifft eine Bedin¬ 
gung nicht zu, wird das Programm einfach 
nach END fortgeführt. 

Das bedeutet in unserem Beispiel, daß die 
Zeilen 10-18 ausgeführt werden, falls Read¬ 
lnt klappt, sonst Zeile 20. Die Struktur wird 
auch durch das Einrücken der entsprechenden 
Programmteile deutlich. In den Zeilen 10-18 
findet sich ein weiteres IF-Konstrukt. Die 
Funktion läßt sich einfacher veranschauli¬ 


chen. wenn man »IF« mit »falls«, »ELSIF« 
mit »ansonsten, falls«, »ELSE« mit »sonst« 
und »THEN« mit »dann« übersetzt. Die IF- 
Konstruktion ist immer mit END abzu¬ 
schließen. 

Ähnlich gewichtig wie Bedingungen sind 
Schleifen. Sie ermöglichen, Programmteile 
mehrmals nacheinander auszuführen. Oberon 
kennt drei Schleifenvarianten. Die erste Art 
bezeichnet man als »offene Schleife«; sie 
wird mindestens einmal durchlaufen. In 
Oberon heißt sie »REPEAT UNTIL«. 


Eine andere Schleifenart ist die »abwei¬ 
sende geschlossene Schleife«. Sie muß nicht 
durchlaufen werden. In Oberon ist dies die 
»WHILE«-Schleife. 

Letztlich bleibt noch die »LOOP«- 
Schleife, die an jeder beliebigen Stelle ver¬ 
lassen werden kann. Mit ihr lassen sich die 
zuvor genannten nachbilden. Trotz des 
schlechten Rufs dieser Schleifenvariante (sie 
schadet der Übersichtlichkeit und Klarheit 
des Quelltexts) kommt man hier und da nicht 
umhin, diese dennoch zu verwenden. 

Die Unterschiede der verschieden Schlei¬ 
fenarten lassen sich an einem alltäglichen 
Beispiel deutlich machen, der Nahrungsauf¬ 
nahme. Solange man Hunger hat, soll geges¬ 
sen werden. Das sieht so aus: 

WHILE Hunger DO 
Essen? 

END; 

Verpackt in eine Repeat-Schleife : 

REPEAT 

Essen; 

UNTIL NOT Hunger; 


Hier ist zu beachten, daß »NOT« nicht in 
der Oberon-Sprachbeschreibung enthalten ist, 
sondern ein Feature von Amiga-Oberon ist. 
Wer portable Programme schreiben möchte, 
sollte »~« anstelle von NOT verwenden. Die 
Funktion ist identisch. 

Auf den ersten Blick erscheint die zweite 
Variante korrekt. Doch was passiert, wenn 
man schon vor der Schleife keinen Hunger 
mehr hatte? Bei der WHILE-Schleife wird 
nicht gegessen, anders bei »REPEAT«: Es 
wird mindestens einmal gegessen. Das aber 


führt zu einer Magenverstimmung. In diesem 
Fall ist also das While-Konstrukt empfeh¬ 
lenswert. Doch auch mit »LOOP« kommt 
man zum Ziel: 

LOOP 

IF NOT Hunger THEN 
EXIT; 

END; 

Essen; 

END; 

Ein gutes Beispiel für Schleifen und 
Bedingungen ist ein Ratespiel mit Zahlen. 
Der Computer bestimmt eine Zahl, der 
Anwender muß sie erraten. Nach jedem Ver¬ 
such erhält man die Information, ob die gera¬ 
tene Zahl größer oder kleiner der Gesuchten 
ist. Hat man die Zahl erraten, ist das Spiel zu 
Ende. In Listing 4 finden Sie die entspre¬ 
chende Implementation in Amiga-Oberon. 

Das Programm beginnt wie gewohnt mit 
dem Modulkopf und den Importen. Nach der 
Konstanten- und Variablendeklaration folgt 
das eigentliche Programm. Zuerst wird die zu 
erratende Zahl ermittelt. Wir verwenden hier¬ 
für die Prozedur »RND« aus dem »Ran- 
dom«-Modul. Sie retourniert eine Zahl zwi¬ 
schen 0 und dem übergebenen Parameter 
minus 1. Um Zahlen zwischen 1 und der 
Konstanten Max zu erhalten, addieren wir 
zum Ergebnis von »r.RND(Max)« noch 1. 
Ansonsten hätten wir lediglich Zahlen von 0 
bis Max-1. Das Ergebnis dieser Berechnung 
wird der Variablen Zahl zugewiesen. 

Es folgt der schon bekannte WriteString- 
Aufruf. Neu ist die Prozedur »Writelnt«, 
ebenfalls aus dem io-Modul. Der erste Para¬ 
meter ist die auf dem Bildschirm auszuge¬ 
bende Zahl. Der zweite die Stellenanzahl. Bis 
hier alles »olle Kamellen«. Der nächste Para¬ 
meter allerdings ist für uns neu: eine 
Schleife. Beim Zahlenraten soll so lange ein 


1 

MODULE Meinung; 


2 

IMPORT 


3 

io; 


4 

VAR 


5 

Eingabe: LONGINT; 


6 

BEGIN 


7 

io.WriteString ('Ihre Meinung zu diesem Programm?\n"); 


8 

io.WriteString Cd) = Gut\n(2) = Schlechten(3) = Naja\n\nMeinung :" 

); 

9 

IF io.Readlnt (Eingabe) THEN 


10 

IF Eingabe = 1 THEN 


11 

io.WriteString ('Wunderbar!\n*); 


12 

ELSIF Eingabe = 2 THEN 

Listing 3: Mei- 

13 

io.WriteString ("Schade!\n"); 

14 

ELSIF Eingabe = 3 THEN 

nung.mod wartet 
auf eine Eingabe 

15 

16: 

io.WriteString ("Na und...\n"); 

ELSE 

17 

io.WriteString ("komische Meinung! nur 1-3 eintippen!\n"); 

und reagiert 

18 

19 

END; (* IF Eingabe *) 

ELSE 

entsprechend mit 

20 

io.WriteString ("Fehlerbei Readlnt() !\n"); 

Hilfe von Fallun¬ 

21 

22 

END; (* IF *) 

END Meinung. © 1993 M&T 

terscheidungen 


Variablentypen von Oberon 

Typ 

Bedeutung 

Werte 

BOOLEAN 

CHAR 

BYTE 

SHORTINT 

INTEGER 

LONGINT 

REAL 

LONGREAL 

SHORTSET 

SET 

LONGSET 

Wahrheitswert 

Zeichen 

Speicherstelle 
kleine Ganzzahl 
Ganzzahl 
große Ganzzahl 
reelle Zahl 
große reelle Zahl 
kleine Menge 

Menge 
große Menge 

TRUE/FALSE 

Steuerzeichen+Buchstaben (OX - OFFX) 

-128 bis 127 oderOX bis OFFX 
-128 bis 127 
-32768 bis 32767 
-2147483648 bis 2147483647 
-9.223317* 10 A 18 bis 9.223317*10*18 
-10*308 bis 10*308 
maximal 8 Elemente (0 bis 7) 
maximal 16 Elemente (0 bis 15) 
maximal 32 Elemente (0 bis 31) 
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1 

MODULE Zahlenraten; 

2 

IMPORT 

3 

io, r: Randora; 

4 

CONST 

5 

Max = 100; 

6 

MaxStellen = 3; 

7 

VAR 

8 

Zahl, Tip: LONGINT; 

9 

BEGIN 

10 

Zahl := r.RND (Max) + 1; 

11 

io.WriteString ("Zahlenraten im 


Bereich von 1-"); 

12: io.Writelnt (Max, MaxStellen); 


io.WriteLn; io.WriteLn; 

13 

REPEAT 

14 

REPEAT 

15 

io.WriteString ("Dein Tip: "); 

16 

UNTIL (io.Readlnt (Tip)) AND 


(Tip >= 1) AND (Tip <= Max); 

17: IF Tip > Zahl THEN 

18 

io.WriteString ("Leider zu 


groß!\n\n"); 

19 

ELSIF Tip < Zahl THEN 

20 

io.WriteString ("Schade, zu 


klein!\n\n"); 

21 

END; (* IF *) 

22 

UNTIL Tip = Zahl; 

23 

io.WriteString ("Geschafft!\n"); 

24 

END Zahlenraten. © 1993 M&T 

Listing 4: Zahlenraten.mod ermit¬ 
telt mit Hilfe des Zufallgenerators 
eine Zahl, die zu erraten ist 


Tip eingeholt werden, bis die gesuchte Zahl 
erraten wurde. Dies wird im Programm durch 
»UNTIL Tip = Zahl« deutlich. Man erkennt, 
daß UNTIL in Zeile 22 mit REPEAT in Zeile 
13 korrespondiert. Das wird auch durch Ein¬ 
rücken der Zeilen 14 bis 21 innerhalb der 
Schleife deutlich. Diese Zeilen werden so 
lange wiederholt, bis die Bedingung hinter 
UNTIL erfüllt (richtig bzw. TRUE) ist. Für 
unseren Zweck ist REPEAT ideal. 

Die zweite Schleife (Zeile 14 bis 16) sorgt 
dafür, daß ein gültiger Tip eingegeben wird. 
Es wird so lange eingelesen, bis Readlnt 
funktioniert hat und der Tip zwischen 1 und 
Max liegt. Die Und-Verknüpfung wird in 
Oberon mit dem Schlüsselwort »AND« 
gekennzeichnet. Es wird deutlich, daß man 
bei WHILE, UNTIL und IF nicht nur eine 
Bedingung angeben kann, sondern zudem die 
Möglichkeit hat, mehrere zu verknüpfen, 
indem man die Einzelbedingungen durch 
»OR« (oder), »AND« (und) und »NOT« 
(nicht) verbindet. AND ist nicht in der 
Sprachbeschreibung vorgesehen. Wer porta¬ 
bel sein möchte, sollte »&« verwenden. 


Werden zwei Bedingungen durch OR ver¬ 
knüpft, ist die Gesamtbedingung bereits mit 
einer der beiden Einzelbedingungen erfüllt. 
Bei AND müssen beide Bedingungen erfüllt 
sein, damit die Einzelbedingung TRUE 
ergibt. NOT verkehrt eine Bedingung in ihr 
Gegenteil. 

Das Programm ist aber noch nicht zu Ende: 
Die verbleibenden Zeilen 17 bis 21 sowie 
Zeile 23 sollte einsichtig sein. Das vorlie¬ 
gende Listing stellt lediglich ein minimales 
Spiel dar. Ihre Aufgabe ist es, das Spiel zu 
erweitern. Zählen Sie beispielsweise die 
Anzahl der Versuche und geben Sie am 
Schluß eine Bewertung aus. Auch die Ober¬ 
grenze des Zahlenbereichs ließe sich variabel 
einrichten und vom Spieler erfragen. Ein Tip: 
Man erhöht eine Variable um eine Zahl mit 
der Anweisung 
Variable := Variable + Zahl; 

Das läßt sich weiter vereinfachen. Fol¬ 
gende Anweisung erfüllt die gleiche Auf¬ 
gabe: 

INC (Variable, Zahl); 

»INC« läßt sich von »Inkrementieren« 
ableiten, was soviel wie »erhöhen« bedeutet. 
Soll eine Zahl nur um den Wert 1 erhöht wer¬ 
den, reicht der Aufruf 

INC (Variable); 

Gleiches gilt zum Reduzieren. Die entspre¬ 
chende Funktion heißt »DEC« und kommt 
von »dekrementieren«. 

Ein weiterer, die Bewertung vereinfachen¬ 
der Befehl, kann mit Hilfe der »CASE«- 
An Weisung vorgenommen werden. Mit 
CASE lassen sich viele IF-Befehle ersetzen 
und so eine einfache Fallunterscheidung vor¬ 
nehmen. Listing 5 (»Note.mod«) verdeutlicht 
das. Es bewertet die Leistung eines Schülers. 
Gleichzeitig finden Sie hier ein Beispiel für 
die LOOP-Schleife. Die Abbruchbedingung 
steht in Zeile 13, das CASE-Konstrukt in den 
Zeilen 11 bis 24. Nach dem Schlüsselwort 
CASE folgt die Variable, auf die sich die 
Fallunterscheidung bezieht. Nach »OF« 
schließen sich die verschiedenen Fälle an, 
eingeleitet mit dem Zeichen »I«. Jeder Fall 
ließe sich durch »IF Zensur =« bzw. »ELSIF 
Zensur =« ersetzen. CASE spart also Tippar¬ 
beit. Dies wird besonders in Zeile 16 deut¬ 


1 

MODULE OhneProcs; (* Ungeschickt *) 

2 

IMPORT 

3 

io; 

4 

VAR 

5 

Jahr, Monat, Tag, Stunde, Minute: LONGINT; 

6 

BEGIN 

7 

REPEAT 

8 

io.WriteString ("Bitte Jahr eingeben: "); 

9 

UNTIL io.Readlnt (Jahr) AND (Jahr >= 0) AND (Jahr <= 2100); 

10 

REPEAT 

11 

io.WriteString ("Bitte Monat eingeben: "); 

12 

UNTIL io.Readlnt (Monat) AND (Monat >= 1) AND (Monat <= 12); 

13 

REPEAT 

14 

io.WriteString ("Bitte Tag eingeben: "); 

15 

UNTIL io.Readlnt (Tag) AND (Tag >= 1) AND (Tag <= 31); 

16 

REPEAT 

17 

io.WriteString ("Bitte Stunde eingeben: "); 

18 

UNTIL io.Readlnt (Stunde) AND (Stunde >= 0) AND (Stunde <= 23); 

19 

REPEAT 

20 

io.WriteString ("Bitte Minute eingeben: "); 

21 

UNTIL io.Readlnt (Minute) AND (Minute >= 0) AND (Minute <= 59); 

22 

(* ... der Rest, der diese Daten verarbeitet *) 

23 

END OhneProcs. © 1993 M&T 

Listing 6: OhneProcs.mod - umständlicher geht’s kaum noch 


lich, in der die Fälle 2, 3 und 4 zu einem 
zusammengefaßt werden. Ohne CASE müßte 
es »IF (Zensur >= 2) AND (Zensur <= 4) 
THEN« heißen. Anzumerken ist, daß in 
Variablen vom Typ »CHAR« ein Zeichen 
gespeichert werden kann. »Read« aus dem 
io-Modul dient zum Einlesen eines Zeichens 
von der Tastatur. 

Prozeduren 

Beschäftigen wir uns jetzt mit Prozeduren. 
Kaum ein Programm kommt ohne sie aus. 
Sie erleichtern u.a. das Verständnis eines 
Programms. In einer Prozedur verpackt man 
Programmteile, die an verschiedenen Stellen 


MODULE Note; 

IMPORT 

io; 

VAR 

Zensur; LONGINT; 

BEGIN 

LOOP 

REPEAT 

io.WriteString ("Bitte Note oder 0 
(= Ende) eingeben: “); 


10 : 

UNTIL io.Readlnt 

(Zensur); 

11 : 

CASE Zensur OF 


12 : 

1 0 : 


13: 

EXIT; 


14: 

1 1 : 


15: 

io.WriteString 

("Echt OK!\n*); 

16: 

1 2..4: 


17: 

io.WriteString 

("Normal\n"); 

18: 

1 5: 


19: 

io.WriteString 

("Gefahr, 



Achtung!\n"); 

20 : 

1 6 : 


21 : 

io.WriteString 

("und 


tschüß.. An"); 

22 : 

ELSE 


23: 

io.WriteString 

("Bitte eine Note 


von 1 bis 6 oder 0 eingeben!\n" 

24: 

END; (* CASE *) 


25: 

END; (* LOOP *) 


26: 

END Note. © 1993 M&T 


Listing 5: Note.mod demonstriert 
mit dem CASE-Operator einfache 
Fallunterscheidungen 


des Programms gebraucht werden. Wir haben 
bisher viele Prozeduren aus dem Modul io 
verwendet. Stellen Sie sich vor. Sie müßten 
jedesmal, wenn Sie eine solche Prozedur auf- 
rufen, anstelle des Aufrufs mehrmals die glei¬ 
chen Schritte wiederholen. Das kostet nicht 
nur Speicherplatz, auch der Übersichtlichkeit 
eines Programms schadet es. 

Der Sinn einer Prozedur? Stellen Sie sich 
vor. Sie sollen mehrere Zahlen von der Tasta¬ 
tur einiesen. Dazu kann man io.Readlnt ver¬ 
wenden. Nun möchten Sie jedesmal einen 
Text ausgeben und, falls beim Einlesen ein 
Fehler auftritt, das Einlesen wiederholen. Sie 
könnten in einer REPEAT-Schleife immer 
die Prozedur io.WriteString und io.Readlnt in 
Anspruch nehmen. Umständlich? Richtig. 
Einfacher geht's mit Prozeduren. Vergleichen 
Sie einmal Listing 6 und 7 miteinander 
(»OhneProcs.mod« bzw. »MitProcs.mod«). 
Bei größeren Prozeduren kann man sich die 
Arbeitsersparnis sicher gut vorstellen. 

Bei »OhneProcs.mod« ist alles klar. Es fol¬ 
gen fünf sich extrem ähnelnde aber dennoch 
unterschiedliche Schleifen. Interessant wird 
es bei »MitProcs.mod«. Hier wird eine neue 
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1: MODULE MitProcs; (* geschickt *) 

2: IMPORT 
3: io; 

4: VAR 

5: Jahr, Monat, Tag, Stunde, Minute: LONGINT; 

6 : PROCEDURE GetNumber (Str: ARRAY OF CHAR; Min, Max: LONGINT): LONGINT; 

7: VAR 

8 : Number: LONGINT; 

9: BEGIN 
10: REPEAT 

11: io.WriteString (Str); 

12: UNTIL io.Readl AND (Number >= Min) AND (Number <= Max); 

13: RETURN Number; 

14: END GetNumber; 

15: BEGIN 


16: 

Jahr 

:= GetNumber 

"Bitte Jahr eingeben: 

0 , 

2100 ) 

17: 

Monat 

:= GetNumber 

"Bitte Monat eingeben: ", 

1 , 

12 ) 

18: 

Tag 

:= GetNumber 

"Bitte Tag eingeben: 

1 , 

31) 

19: 

Stunde 

:= GetNumber 

"Bitte Stunde eingeben: ", 

0 , 

23) 

20 : 

Minute 

:= GetNumber 

("Bitte Minute eingeben: ", 

0 , 

59) 

21 : 

<* ... 

der Rest, der diese Daten verarbeitet *) 



22 : 

END MitProcs. 

© 1993 M&T 




Listing 7: MitProcs.mod ist die geschickte Umsetzung von »OhneProcs.mod« 
und ersetzt sich oft wiederholende Funktionen durch Prozeduren 


Prozedur »GetNumber« geschaffen. Das 
erkennt man am Schlüsselwort »PROCE¬ 
DURE«. Es folgen die Parameter, durch 
Klammern umschlossen. Es gibt auch Proze¬ 
duren ohne Parameter (z.B. io.WriteLn). Die 
einzelnen Parametergruppen sind durch 
Semikola getrennt. In unserem Beispielpro¬ 
gramm »MitProcs.mod« existieren für die 
Prozedur GetNumber die Parameter »Str«, 
»Min« und »Max«. Dabei hat Str den Typ 
»ARRAY OF CHAR«, auf den wir später 
genauer eingehen. Es genügt hier zu wissen, 
daß darin eine Zeichenkette abgelegt werden 
kann. Min und Max sind LONGINT-Parame- 
ter. Diese können innerhalb der Prozedur wie 
Variablen behandelt werden. Folgt nach der 
schließenden Klammer ein Doppelpunkt 
sowie eine Typbezeichnung, handelt es sich 
bei der Prozedur um eine Funktion, die ein 
Ergebnis des angegebenen Typs retourniert. 
Prozeduren liefern von sich aus keine Rück¬ 
gabewerte. 

1: MODULE Raetsel; 

2: IMPORT 
3: io; 

4: VAR 

5: a: INTEGER; 

6 : PROCEDURE Ping (VAR x: INTEGER); 

7: BEGIN 

8 : DEC (x, 10); 

9: END Ping; 

10: PROCEDURE Pong (y: INTEGER); 

11: BEGIN 

12 : y := y * 2 ; 

13: END Pong; 

14: PROCEDURE Zoom; 

15: BEGIN 

16: INC (a, 22); 

17: END Zoom; 

18: PROCEDURE Boom; 

19: VAR 

20: a: ARRAY 10 OF CHAR; 

21: BEGIN 

22: a := "Hallo!"; 

23: END Boom; 

24: BEGIN 
25: a := 20; 

26: Zoom; 

27: Boom; 

28: Pong (a); 

29: Ping (a); 

30: io.WriteString ("a ist jetzt: "); 

31: io.Writelnt (a, 2); 

32: io.WriteLn; 

33: END Raetsel. © 1993 M&T 

Listing 8: Raetsel.mod - welchen 
Wert besitzt die globale Variable a 
am Programmende? 


Es schließen sich, je nach Bedarf, die Kon¬ 
stanten-, Typen- und Variablendeklarationen 
an, die nur für diese Prozedur gelten und 
sichtbar sind. Die Parameter innerhalb einer 
Prozedur lassen sich ohne Auswirkungen 
(Seiteneffekte) auf übrige Programmteile ver¬ 
ändern. 

Es gibt aber noch einen weiteren Parame¬ 
tertyp. Ein Beispiel ist io.Readlnt. Diese 
Funktion verändert den Inhalt der übergebe¬ 
nen Variable. Das läßt sich auch in eigenen 
Prozeduren bewerkstelligen, indem dem 
Parameternamen ein »VAR« vorangestellt 
wird. Wird ein VAR-Parameter innerhalb 
einer Prozedur/Funktion modifiziert, ändert 
sich auch der Inhalt der Variablen, die über¬ 
geben wurde. 

In Prozeduren ist es möglich, auf Variablen 
des umgebenden Moduls zuzugreifen und 
diese zu verändern. Ein Sonderfall ist aller¬ 
dings zu beachten: Besitzt eine lokale Varia¬ 
ble den gleichen Namen wie eine globale, 
dann ist die globale Variable innerhalb der 
Prozedur unsichtbar und unerreichbar. Sie 
läßt sich weder auslesen noch verändern, 
denn der Compiler bezieht sich immer auf die 
lokale Variable. 

Der Prozedurkörper zwischen den Schlüs¬ 
selwörtern BEGIN und END beinhaltet als 
Neuerung eigentlich nur noch »RETURN«. 
RETURN verläßt eine Prozedur. Ist die Pro¬ 
zedur eine Funktion, ist RETURN, gefolgt 
vom Ergebnis, notwendig. Ansonsten steht es 
alleine. Das Ergebnis einer Funktion (Proze¬ 
dur mit Rückgabewert) läßt sich einer Varia¬ 
blen zuweisen. 

Man sieht, daß Prozeduren kleine, in sich 
abgeschlossene und autonome Programmteile 
sind, die ihre eigenen Variablen und Typen 
haben können. Außerdem ist es möglich, auf 
alle Elemente des Moduls zuzugreifen. Pro¬ 
zeduren dürfen auch innerhalb von Prozedu¬ 
ren auftreten, also geschachtelt werden: Sie 
sind dann allerdings nur innerhalb der 
umschließenden Prozedur sichtbar. Mit ihrer 
Umwelt treten Prozeduren durch Parameter 
und Rückgabewert in Verbindung. 

Bringen wir nun unser Beispiel »Mit¬ 
Procs.mod« zu Ende: Im BEGIN-Teil des 
Moduls wird die Prozedur fünfmal mit den 


passenden Parametern aufgerufen. Es ist zu 
beachten, daß die Ausführung des Pro¬ 
gramms weiterhin mit dem BEGIN-Teil des 
Moduls startet. Prozeduren werden nur aus¬ 
geführt, wenn man sie aufruft, auch wenn sie 
vor dem BEGIN-Block stehen. 

Fassen wir zusammen: Es existieren zwei 
Parametertypen: Einfache Parameter und 
VAR-Parameter. Ein Beispiel für einfache 
Parameter ist die Prozedur Hi: 

PROCEDURE Hi (a: INTEGER); 

BEGIN 

TuDies; 

TuDas; 

END Hi; 

Ruft man sie mit »Hi (42);« auf, passiert dies: 

1. a := 42; 

2. TuDies; 

3. TuDas; 

Eine Beispielprozedur für VAR-Parameter 
ist: 

PROCEDURE Bye (VAR c: CHAR); 

BEGIN 

MachJenes; 

VersucheDieses; 

END Bye; 

Diese läßt sich z.B. so aufrufen: »Bye 
(Chr);«, wobei Chr eine Variable vom Typ 
CHAR ist. Die Ausführung sieht dann so aus: 


1 

MODULE Multiplikation; 

2 

IMPORT 

3 

io; 

4 

CONST 

5 

Max = 15; 

6 

Stellen = 3; 

7 

VAR 

8 

Tabelle: ARRAY Max, Max OF INTEGER; 

9 

x, y: INTEGER; 

10 

BEGIN 

11 

x := 0 ; 

12 

REPEAT 

13 

y := 0 ; 

14 

REPEAT 

15 

Tabelle[x, y] := (x+1) * (y+1); 

16 

INC (y); 

17 

UNTIL y = Max; 

18 

INC (x); 

19 

UNTIL x = Max; 

20 


21 

(* ... *) 

22 


23 

x := 0 ; 

24 

REPEAT 

25 

y := 0 ; 

26 

REPEAT 

27 

io.Writelnt (Tabeile[x, y], 


Stellen +.1); 

28 

INC (y); 

29 

UNTIL y = Max; 

30 

io.WriteLn; 

31 

INC (x); 

32 

UNTIL x = Max; 

33: END Multiplikation. © 1993 M&T 

Listing 9: Multiplikation.mod zeigt, 
wie in Oberon mit mehrdimensio- 

nalen Arrays gerechnet wird 


1. c := Chr; 

2. MachJenes; 

3. VersucheDieses; 

4. Chr := c; 

Man sieht, daß sich auch die übergebene 
Variable (»Chr«) ändert, wenn man innerhalb 
der Prozedur »c« modifiziert. 

Ein kleines Rätsel: Was gibt das Programm 
»Raetsel.mod« (Listing 8) aus? Es ist zu 
beachten, daß nur die Änderung von VAR- 
Parametem Auswirkungen auf das umge- 
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Max); 


MODULE ZahlenratenDeLuxe; 

IMPORT 

io, r: Random; 

VAR 

Zahl, Tip, Max, Versuche: LONGINT; 
jn, dummy: CHAR; 

BEGIN 

io.WriteString (*Zahlenraten!\n\n"); 

REPEAT 
REPEAT 

io.WriteString ("Bitte oberen Grenze eingeben: 

UNTIL io.Readlnt (Max) AND (Max > 1); 

Zahl := r.RND (SHORT (Max)) + 1; 

Versuche := 0; 

REPEAT 
REPEAT 

io.WriteString ("Dein Tip: *); 

UNTIL (io.Readlnt (Tip)) AND (Tip >= 1) AND (Tip c 
INC (Versuche); 

IF Tip > Zahl THEN 

io.WriteString ("Leider zu groß!\n\n"); 

ELSIF Tip < Zahl THEN 
io.WriteString ("Schade, zu klein!\n\n"); 

END; (* IF ♦) 

UNTIL Tip = Zahl; 

io.WriteString ("Geschafft in"); io.Writelnt (Versuche, 
io.WriteString (" Versuchen!\n"); 

CASE Versuche OF (* ungerecht, da Max sich ändern kann. Na und! 
! 1..3: 

io.WriteString ("Voll goil, ey!\n'); 

I 4..10: 

io.WriteString ("Gut, Mann/Frau!\n"); 

I 11..20: 

io.WriteString ("Naja...\n"); 

ELSE 

io.WriteString ("Hahahahaha, üben!!!\n"); 

END; (* CASE *) 

REPEAT 

io.WriteString ("\nNochmal (j/n)? "); 
io.Read (jn); 

jn := CAP (jn); (* in Großbuchstaben umwandeln *) 
io.Read (dummy); (* nochmal, da <RETURN> überlesen werden muß 
UNTIL (jn = "J") OR (jn = "N"); 

UNTIL jn = "N"; 

END ZahlenratenDeLuxe. © 1993 M&T 


3); 


Listing 10: ZahlenratenDe- 
Luxe.mod ist eine verbesserte 
Version von Listing 4, 
»Zahlenraten.mod« 


bende Programm hat. Tauchen in Prozeduren 
Variablen mit dem gleichen Namen wie im 
Modul auf, gelten für die Prozedur die eige¬ 
nen Variablen. 

Nachdem die Importe, Variablen und Pro¬ 
zeduren vereinbart wurden, wird als erste 
Anweisung im BEGIN-Teil a der Wert 20 
zugewiesen. Anschließend rufen wir »Zoom« 
auf. Diese erhöht den Wert der globalen 
Variable a um 22. a hat jetzt den Wert 42. 
Man sieht, daß sich in Prozeduren globale 
Variablen problemlos ändern lassen. 

Jetzt folgt »Boom«. Sie verfügt über eine 
lokale Variable, deren Name mit der einer 
globalen identisch ist. Lokal bedeutet, daß 
die Variable nur für diese Prozedur bestimmt 
ist. Eigentlich sollte man eine solche Pro¬ 
grammierung vermeiden, da sie zu uner¬ 
wünschten Verwechslungen führen kann. Die 
neue lokale Variable ist von der globalen völ¬ 
lig unabhängig. Demzufolge ist es auch mög¬ 
lich, ihr einen anderen Typ als der globalen 
zu geben. Die globale a behält also seinen 
Wert 42, auch wenn die lokale Variable a auf 
»Hallo!« gesetzt wird. 

Wir sind noch nicht zu Ende. Es folgt der 
Aufruf der Prozedur »Pong«. Ihr übergeben 
wir den Wert der globalen Variablen a, also 
42. Innerhalb der Prozedur wird der überge¬ 
bene Parameter verdoppelt. Dies hat aber 
keinerlei Auswirkungen aufs Hauptpro¬ 
gramm. Der Parameter y existiert nur inner¬ 
halb der Prozedur, a behält den Wert 42. 

Anders ist dies bei »Ping«. Sie besitzt den 
VAR-Parameter x. Wir wissen, daß VAR 
dafür sorgt, daß sich Änderungen an diesem 
Parameter auch auf das Hauptprogramm aus¬ 
wirken. In unserem Fall bedeutet es, daß, 
wenn x geändert wird, auch a den neuen Wert 
übernimmt. Hier werden also x und a um den 
Wert 10 vermindert und besitzen beide den 
Wert 32. Damit ist das Rätsel gelöst und das 
Programm gibt 32 als Wert für a aus. 

Weitere Basistypen 

Bis jetzt wurden nur die einfachen numeri¬ 
schen Datentypen besprochen. Es existieren 
aber noch weitere. Man kann diese sogar 
kombinieren. Um ein Zeichen zu speichern, 
bietet sich der Typ CHAR an. Dann gibt es 

1: MODULE Open; 

2: IMPORT 

3: io; 

4: PROCEDURE esreveR (Str: ARRAY OF CHAR); 

5: VAR 

6 : i: LONGINT; 

7: BEGIN 

8 : i := LEN (Str)-l; (* Nullbyte 

(Stringende) nicht ausgeben *) 

9: WHILE i >= 0 DO 

10: io.Write (Str[i]); (* Ein Zeichen 

ausgeben *) 

11: DEC (i); 

12: END; 

13: io.WriteLn; 

14: END esreveR; 

15: BEGIN 

16: esreveR ("Hallo Leute!"); 

17: esreve'R ("Oberon ist einfach toll!"); 

18: esreveR ("Was ist wohl 'esreveR'?"); 

19: END Open. © 1993 M&T 

Listing 11: Open.mod arbeitet mit 
offenen Arrays 


noch den Außenseiter »BYTE«, der vor 
allem beim Zugriff auf das Betriebssystem 
von Bedeutung ist. Eine Sonderstellung 
nimmt der Typ »ARRAY OF BYTE« ein, 
der zu allen anderen Array-Typen kompatibel 
ist. Auf Arrays gehen wir noch genauer ein. 

Variablen, die als »BOOLEAN« definiert 
wurden, können Wahrheitswerte speichern. 
Diese kennen nur zwei Zustände: TRUE für 
wahr und FALSE für unwahr bzw. falsch. 
Der Zweck solcher Variablen wird an einem 
Beispiel deutlich. Ein Programm fragt am 
Anfang den Benutzer, ob er englische oder 
deutsche Benutzerführung will. Die BOOL¬ 
EAN-Variable »Deutsch« wird mit »:=« ent¬ 
sprechend belegt. Mit IF läßt sich eine Fall¬ 
unterscheidung vornehmen: 

IF Deutsch 

THEN 

io.WriteString ("Apfel"); 

ELSE 

io.WriteString ("Apple"); 

END; 

Als weiteren Basistyp gibt es noch die 
Gruppe der Sets (»SHORTSET«, »SET« und 
»LONGSET«). Sie repräsentieren jeweils 
eine Menge mit 8, 16 oder 32 Elementen. 
Das läßt erahnen, daß sich eine Menge also 
aus mehreren Elementen zusammensetzt. 
Wer in der Grundschule Mengenlehre hatte, 
wird sich hier heimisch fühlen. Jedes ein¬ 
zelne Element ist entweder in der Menge ent¬ 
halten oder nicht. Die Elemente werden ab 0 
aufwärts durchnumeriert. Es empfiehlt sich, 
den einzelnen Elementen Namen zu geben, 
indem man Konstanten vereinbart. 


Als Beispiel einer Menge kann eine Schub¬ 
lade dienen, in der sich Gegenstände befin¬ 
den (oder auch nicht). Die einzelnen Gegen¬ 
stände werden von 0 an numeriert: 

CONST 

Geld = 0; 

Papier = 1; 

Bleistift = 2; 

Kuli = 3; 

Buntstift = 4; 

Heft = 5; 

Besteck = 6; 

Anschließend ist die Schublade zu definieren: 

VAR Schublade: SHORTSET; 

Um der Schublade einen Inhalt zuzuweisen, 
schreibt man: 

Schublade := SHORTSET { 

Heft, 

Buntstift, 

Papier 

}; 

Jetzt befinden sich diese drei Elemente in 
der Schublade. Man legt weitere Dinge hin¬ 
ein mit: 

Schublade := Schublade + 

SHORTSET {Geld, Besteck}; 

Um nur ein Element hinzuzufügen: 

INCL (Schublade, Kuli); 

Elemente entfernt man mit: 

Schublade := Schublade - 

SHORTSET {Kuli, Papier}; 

bzw. 

EXCL (Schublade, Geld); 

Möchte man wissen, was sowohl in S1 als 
auch in S2 (beide vom Typ »SHORTSET«) 
liegt: 
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1 

MODULE Init; 

kein Speicher! *) 


2 

IMPORT 

57 



3 

io; 

58 

COPY (Name, NeuesFeld.name); 

4 

CONST 

59 

NeuesFeld.Spieler := 

SET {}; 

5 

Blau = 0; 

60 

RETURN NeuesFeld; 


6 

Gruen = 1; 

61 

END InitFeld; 


7 

Violett = 2; 

62 

PROCEDURE InitStrasse 


8 

(* ... *) 


(Name: ARRAY OF CHAR; 

9 

TYPE 

63 

Preis: INTEGER; 


10 

Feld = RECORD 

64 

Farbe: INTEGER; 


11 

name: ARRAY 50 OF CHAR; 

65 

Miete: Tarife): StrassePtr; 

12 

Spieler: SET; 

66 

VAR 


13 

END; 

67 

NeueStrasse: StrassePtr; 

14 

FeldPtr = POINTER TO Feld; 

68 

BEGIN 


15 

Kaeuflich = RECORD (Feld) 

69 

NEW (NeueStrasse); (* 

Speicher holen *) 

16 

preis: INTEGER; 

70 

IF NeueStrasse = NIL THEN HALT (20) 

17 

hypothek: BOOLEAN; 


END; (* kein Speicher! *) 

18 

gekauft: BOOLEAN; 

71 

COPY (Name, NeueStrasse.name); 

19 

END; 

72 

NeueStrasse.Spieler 

= SET {}; 

20 

KaeuflichPtr = POINTER TO Kaeuflich; 

73 

NeueStrasse.preis 

= Preis; 

21 

Tarife = ARRAY 6 OF INTEGER; 

74 

NeueStrasse.hypothek 

= FALSE; 

22 

Strasse = RECORD (Kaeuflich) 

75 

NeueStrasse.gekauft 

= FALSE; 

23 

färbe: INTEGER; 

76 

NeueStrasse.färbe 

= Farbe; 

24 

haeuser: INTEGER; 

77 

NeueStrasse.haeuser 

= 0; 

25 

miete: Tarife; 

78 

NeueStrasse.miete 

= Miete; 

26 

END; 

79 

RETURN NeueStrasse; 


27 

StrassePtr = POINTER TO Strasse; 

80 

END InitStrasse; 


28 

Bahnhof = RECORD (Kaeuflich) 

81 

PROCEDURE InitBahnhof 


29 

END; 


(Name: ARRAY OF CHAR; 

30 

BahnhofPtr = POINTER TO Bahnhof; 

82 

Preis: INTEGER): BahnhofPtr; 

31 

(* ... weitere Typen ... *) 

83 

VAR 


32 

VAR 

84 

NeuerBahnhof: BahnhofPtr; 

33 

Plan: ARRAY 40 OF FeldPtr; 

85 

BEGIN 


34 

PROCEDURE Kaufen (VAR KaufFeld: FeldPtr); 

86 

NEW (NeuerBahnhof);(* 

Speicher holen *) 

35 

BEGIN 

87: 

IF NeuerBahnhof = NIL THEN HALT (20) 

36 

IF KaufFeld IS Kaeuflich THEN (* 


END; (* kein Speicher! *) 


Typtest !!! *) 

88 

COPY (Name, NeuerBahnhof.name); 

37 

WITH KaufFeld: Kaeuflich DO 

89 

NeuerBahnhof.Spieler 

:= SET {}; 

38 

IF KaufFeld.gekauft THEN 

90 

NeuerBahnhof.preis 

:= Preis; 

39 

io.WriteString (KaufFeld.name); 

91 

NeuerBahnhof.hypothek 

:= FALSE; 

40 

io.WriteString (* ist schon 

92 

NeuerBahnhof.gekauft 

:= FALSE; 


verkauft!\n*); 

93 

RETURN NeuerBahnhof; 


41 

: ELSE 

94 

END InitBahnhof; 


42 

: KaufFeld.gekauft := TRUE; 

95 

(* ... *) 


43 

: (* ... *) 

96 

BEGIN 


44 

: END; 

97 

Plan[0] := InitFeld ( 

"Start"); 

45 

: END; 

98 

Plan[1] := 


46 

: ELSE 


InitStrasse ("Oberonweg", 333, Blau, 

47 

: io.WriteString (KaufFeld.name); 

99 


Tarife (10, 50, 

48 

: io.WriteString (" kann nicht gekauft 

100 

150, 200, 500)); 



werden!\n"); 

100 

: (* ... *) 


49 

: END; 

101: Plan[5] := InitBahnhof 

50 

: END Kaufen; 


("Hauptbahnhof*, 500); 

51: PROCEDURE InitFeld 

102 

: <* ... *) 



(Name: ARRAY OF CHAR): FeldPtr; 

103: Kaufen (Plan[0]); 


52 

: VAR 


Kaufen (Plan(1]); Kaufen (Plan[1]); 

53 

: NeuesFeld: FeldPtr; 

104: END Init. © 1993 M&T 

54 

55 

: BEGIN 

: NEW (NeuesFeld); (* Speicher holen *) 

Listing 12: Init.mod - Pointer, Re- 

56: IF NeuesFeld = NIL THEN HALT (20) END; (* 

cords und sonstige üble Dinge 


InBeiden := S1 * S2; 

Als letzten Mengenoperator gibt es noch: 

InEiner := S1 / S2; 

Mit »/« erhält man alle Elemente, die in S1 
oder S2 sind, aber nicht in beiden gleichzei¬ 
tig. Dabei ist unbedingt zu beachten, daß sich 
in Mengen nur feststellen läßt, ob ein Ele¬ 
ment enthalten ist. Ein spezielles Element 
kann also nicht mehrmals Vorkommen. Zwei¬ 
malige Anweisung von »INCL (Sl, 2)« be¬ 
wirkt dasselbe wie nur eine. Anschließend ist 
das Element »2« in der »Sl« enthalten. 

Häufig tritt das Problem auf, viele gleich¬ 
artige Daten zu speichern (z.B. Tabellen). Für 
eine zehnspaltige Tabelle ließen sich mit 
VAR a, b, c, d, e, f, g, h, i, j: INTEGER; 
die passenden Variablen bereitstellen. Um¬ 
ständlich. Das wird spätestens dann deutlich, 
wenn man die Tabelleneinträge aufaddieren 
möchte. Bei zehn Werten mag es noch mög¬ 
lich sein, doch was ist bei 1 000 oder mehr? 

Die Lösung sind sog. Arrays. Sie dienen 
dazu, viele gleichartige Variablen in einer 
Tabelle zusammenzufassen. Die Syntax der 
Variablendefinition ist: 


VAR Tab: ARRAY 1000 OF INTEGER; 

Damit hat man auf einen Schlag 1000 
Variablen definiert. Die erste davon heißt 
»Tab[0]«, die letzte »Tab[999]«. Um alle 
Elemente dieser Tabelle zu addieren, schreibt 
man: 

Summe := 0; 

Nummer := 0; 

WHILE Nummer < 1000 DO 
INC (Summe, Tab[Nummer]); 

INC (Nummer); 

END; 

Man sieht, Arrays und Schleifen vertragen 
sich prima. 

Da aber auch häufig Tabellen mit mehre¬ 
ren Spalten benötigt werden, muß es weitere 
Definitionsmöglichkeiten geben. Oberon be¬ 
herrscht auch das. Listing 9 (»Multiplika¬ 
tion.mod«) demonstriert die Arbeit mit mehr¬ 
dimensionalen Arrays. Zunächst legen wir 
eine Tabelle mit 15 x 15 Elementen an. Die 
Konstante »Max« wurde zuvor mit dem Wert 
15 besetzt. Man sieht: Die Dimension wird 
nach dem Schlüsselwort »Array« angegeben. 
Gibt es mehrere, sind diese durch Kommata 


zu trennen. Anschließend füllen wir die 
Tabelle mit Werten und geben sie auf dem 
Bildschirm aus. 

Kommen mehrere gleichartige Arrays in 
einem Modul vor oder möchte man einem 
Array einen vielsagenden Namen geben, legt 
man einfach einen neuen Typ an: 

TYPE Tab = ARRAY 10 OF INTEGER; 

Dieser läßt sich nun bei der Variablende¬ 
klaration einsetzen: 

VAR Alter, Groesse: Tab; 

Man könnte auch schreiben 

VAR Alter, Groesse: ARRAY 10 OF INTEGER; 

Der Vorteil der ersten Schreibweise mit 
eigenem Typ ist die, daß sich alle Variablen 
dieses Typs problemlos einander zuweisen 
lassen. 

Im übrigen sind Zeichenketten (Strings) 
auch Arrays, und zwar vom Typ CHAR. Die 
Definition geschieht also mit »ARRAY OF 
CHAR«. Einer so deklarierten Variablen 
kann mit Hilfe des Zuweisungssymbols »:=« 
ein in Anführungszeichen eingeschlossener 
String übergeben werden. Auf die Buchsta¬ 
ben ist, wie bei Arrays üblich, mit »[]« zuzu¬ 
greifen. Möchte man also das 13. Zeichen der 
Zeichenkette »Str« in Erfahrung bringen, 
genügt die Anweisung Str[ 12], Im letzten 
Element der Zeichenkette befindet sich ein 
Null-Byte (»\0«) als Ende-Kennung. Gerade 
bei der Programmierung des Amiga-Betriebs- 
systems ist es besonders wichtig, Zeichenket¬ 
ten mit einem Null-Byte abzuschließen. 

Anders als z.B. bei BASIC sind Befehle 
zur Manipulation von Zeichenketten nicht im 
Sprachkem von Oberon enthalten. Das muß 
nicht unbedingt ein Nachteil sein, denn die 
benötigten Prozeduren stehen als Modul 
bereit: es heißt »Strings« und liegt dem Com¬ 
piler bei. 

Eine weitere Besonderheit sind offene 
Arrays. Bis jetzt kennen wir nur solche mit 
einer definierten Länge: sie haben wir bei der 
Variablendefinition angegeben. Offene Ar¬ 
rays verfügen über keine bestimmte Länge 
und existieren nur in Verbindung mit Proze¬ 
dur-Parametern. Im Prozedurkopf läßt sich 
als Parametertyp ein Array ohne Größenan¬ 
gabe vereinbaren. So lassen sich Arrays 
beliebiger Größe übergeben. Innerhalb der 
Prozedur kann die Länge dann mit »LEN 
(Array)« in Erfahrung gebracht werden. Ein 
Beispiel für diese Technik sind viele Proze¬ 
duren im io-Modul. Ein Beispiel ist Listing 
10, »Open.mod«. 

Records und Pointer 

Neben Arrays kennt Oberon weitere Mög¬ 
lichkeiten, Variablen zu strukturieren und 
gruppieren: Records. Ein Record faßt mehre¬ 
ren Typen (z.B. logisch zueinander passende 
Variablen) zu einem neuen zusammen. 

Beim Brettspiel »Monopoly« gehört z.B. 
zu einem Feld ein Name und es muß zudem 
vermerkt werden, welche Spieler auf diesem 
Feld stehen. Es bietet sich diese Form an: 

TYPE 

Feld = RECORD 
name: ARRAY 50 OF CHAR; 
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Spieler: SET; 

END; 

VAR 

Los: Feld; 

Schon hat man einen neuen (Record-) Typ 
geschaffen, der zwei verschiedene Variablen 
enthält: name und Spieler. Der Zugriff auf die 
einzelnen Strukturelemente erfolgt mit dem 
Zeichen ».«: 

io.WriteString (Los.name); 

Doch die meisten Monopoly-Felder haben 
weitere Eigenschaften: Felder, die gekauft 
werden können, haben einen Preis und es 
kann eine Hypothek aufgenommen werden: 

1: MODULE ArgDemo; 

2: IMPORT 

3: arg: Arguments, io; 

4: VAR 

5: i: INTEGER; 

6 : str: ARRAY 80 OF CHAR; 

7: BEGIN 

8 : i := arg.NumArgs(); 

9: WHILE i > 0 DO 

10: io.Writelnt (i, 2); 

11: io.WriteString (': "); 

12: arg.GetArg (i, str); 

13: io.WriteString (str); 

14: io.WriteLn; 

15: DEC (i); 

16: END; 

17: io.WriteString ("Das Programm heißt: "); 

18: arg.GetArg (0, str); 

19: io.WriteString (str); 

20: io.WriteLn; 

21: END ArgDemo. 

© 1993 M&T 

Listing 13: ArgDemo.mod wertet 
die CLI/Shell- oder Workbench- 
Argumente aus 


TYPE 

Kaeuflich = RECORD (Feld) 
preis: INTEGER; 
hypothek: BOOLEAN; 
gekauft: BOOLEAN; 

END; 

Schon taucht eine weitere Neuerung auf: 
Nach dem Schlüsselwort RECORD erscheint 
ein anderer Record-Typ in Klammern. Das 
bedeutet, daß die Elemente des Basistyps (so 
bezeichnet man den Record in Klammern, 
hier also Feld) ebenfalls im neuen Typ inte¬ 
griert sind. Auf diese Art verpassen wir also 
käuflichen Feldern einen Namen. Eine Straße 
und ein Bahnhof lassen sich so einrichten: 

TYPE 

Tarife = ARRAY 6 OF INTEGER; 

Strasse = RECORD (Kaeuflich) 
färbe: INTEGER; 
haeuser: INTEGER; 
miete: Tarife; 

END; 

Bahnhof = RECORD (Kaeuflich) 

END; 

»Strasse« beinhaltet weitere Elemente, 
»Bahnhof« hingegen kennt lediglich die glei¬ 
chen wie »Kaeuflich«. Daß man trotzdem 
einen neuen Typ definiert, kommt nicht von 
ungefähr. Mit Typtests kann man so später in 
Erfahrung bringen, ob ein Feld ein Bahnhof 
ist oder nicht. 

Der große Vorteil dieser Definition - man 
bezeichnet das auch als Vererbung von Ele¬ 
menten der Basistypen -, ist, daß sich Proze¬ 


duren mit eben solchen Parametern ent¬ 
wickeln lassen. So ließe sie sich mit dem 
Parameter »Strasse« aufrufen, da Strasse eine 
Erweiterung von »Kaeuflich« und damit auch 
von »Feld« ist. Prozeduren mit dem Parame¬ 
ter »Kaeuflich« (z.B. Straße kaufen oder 
Hypothek aufnehmen) verweigern hingegen 
die Arbeit bei einfachen Feldern, jedoch nicht 
bei Straßen oder Bahnhöfen. Wäre es nicht 
schön, wenn sich mit 
VAR Plan: ARRAY 40 OF Feld; 
gleichzeitig alle 40 Variablen für die ver¬ 
schiedenen Feldtypen anlegen ließen? Im 
Prinzip ja, wäre da nicht ein Stein im Weg, 
den es wegzuräumen gilt: leider sind nicht 
alle Felder eines Monopoly-Spiels identisch. 
»Plan[l]« z.B. ist eine Straße, die sich nicht 
einfach einer Variable vom Typ »Feld« 
zuordnen läßt. »Strasse« beinhaltet »Feld«, 
aber »Feld« nicht »Strasse«. 

Einen Ausweg bieten »Pointer« (deutsch: 
Zeiger). Einige werden sie vielleicht von der 
Programmiersprache C kennen, in der Pointer 
zum Alltag gehören. In C allerdings ist die 
Arbeit mit Pointer nicht immer ungefährlich, 
da die simplen Compiler viel zu viel fehler¬ 
hafte Pointer-Operationen durchgehen lassen. 
Die Notation von Oberon und der Überprü¬ 
fungsvorgang des Compilers nehmen den 
Zeigern jedoch ihre Gefährlichkeit. 

Jede Variable wird in einer bestimmten 
Speicherzelle im Hauptspeicher des Compu¬ 
ters abgelegt. Diesen Platz bezeichnet man 
als die Adresse der Variable. Der Datentyp, 
in dem Adressen gespeichert werden, sind 
Zeiger. Einen Zeiger definiert man in Oberon 
so: 

VAR StartAdr: POINTER TO Feld; 

bzw. 

TYPE FeldPtr = POINTER TO Feld; 

VAR StartAdr: FeldPtr; 

Man erkennt, daß in Oberon Zeiger an 
einen Typ gebunden sind. In einer Variablen 
vom Typ »FeldPtr« kann man also nur die 
Adresse einer Variable vom Typ »Feld« spei¬ 
chern. 

Wofür benötigen wir nun aber Zeiger für 
das Monopoly-Spiel? Wir wissen, daß 
»Strasse« eine Erweiterung von »Feld« ist. 
Ein Zeiger aufs »Feld« kann dementspre¬ 
chend auch auf Variablen vom Typ »Strasse« 
zeigen. Unser Spielplan sieht jetzt so aus: 

VAR Plan: ARRAY 40 OF FeldPtr; 

Doch Vorsicht. Mit dieser Deklaration hat 
man 40 Variablen definiert, die Adressen von 
Feldern speichern können. Die Felder selbst 
hat man damit noch nicht angelegt. Dies muß 
explizit mit der Funktion »NEW« geschehen, 
die den benötigten Speicher reserviert, in 
dem die Elemente abzulegen sind. Es bietet 
sich an, für jede Feldart eine eigene Prozedur 
zu programmieren, die die einzelnen Ele¬ 
mente mit Werten belegt. Listing 12 
(»Init.mod«) zeigt, wie das funktioniert. 

Die Funktion »COPY« in Listing 12 
kopiert die String variablen. Eine direkte 
Zuweisung mit »:=« ist nicht möglich, da die 
Zeichenkettenvariablen unterschiedliche Län¬ 
gen haben. Bei Copy muß man auf die Rei¬ 


henfolge der Parameter achten. Sie ist 

COPY (Quelle, Ziel); 

was der Anweisung 

Ziel := Quelle; 

entspricht. 

Ebenfalls neu ist der Gebrauch strukturier¬ 
ter Konstanten. Eine solche verwenden wir 
beim Aufruf der Prozedur »InitStrasse«. Was 
auf den ersten Blick wie ein Sprung zur Pro¬ 
zedur »Tarife« aussieht, ist in Wirklichkeit 
eine strukturierte Konstante vom Typ 
»Tarife«. Man kann erkennen, daß sich so 
alle Array- oder Record-Werte in einem 
Rutsch zuweisen lassen. Vorsicht: Struktu¬ 
rierte Konstanten sind nur mit Amiga-Oberon 
möglich, der Original-Oberon-Report von N. 
Wirth sieht sie nicht vor. 

In der Prozedur »Kaufen« taucht plötzlich 
eine »WITH«-Anweisung auf. Mit ihr läßt 
sich erzwingen, daß eine Variable innerhalb 
des WITH-Blocks so behandelt wird, als sei 
sie von dem Typ, der nach dem »:« angege¬ 
ben ist. Dieser muß allerdings eine Erweite¬ 
rung vom Typ der Variablen sein, sonst gibt’s 
einen Laufzeitfehler. Per »IS« kann man prü¬ 
fen, ob eine Variable einen bestimmten Typ 
hat. Wir tun das in der Zeile vor der WITH- 
Anweisung. 


1 

MODULE China; 

2 

IMPORT 

3 

io, fs: FileSystem, a: Arguments; 

4 

VAR 

5 

In, Out: fs.File; 

6 

Chr: CHAR; 

7 

Arg: ARRAY 80 OF CHAR; 

8 

BEGIN 

9 

IF a.NumArgsO « 2 THEN 

10 

io.WriteString ("Usage: '); 

11 

a.GetArg (0, Arg); 

12 

io.WriteString (Arg); 

13 

io.WriteString (■ InFile/A, 

OutFile/A\n-); 

14 

HALT (20); 

15 

END; 

16 

a.GetArg (1, Arg); 

17 

IF NOT fs.Open (In, Arg, FALSE) THEN 

18 

io.WriteString ("Can't open *); 

19 

io.WriteString (Arg); 

20 

io.WriteString (■ for input!\n'); 

21 

HALT (20); 

22 

END? (* IF *) 

23 

a.GetArg (2, Arg); 

24 

IF NOT fs.Open (Out, Arg, TRUE) THEN 

25 

io.WriteString ('Can’t open "); 

26 

io.WriteString (Arg); 

27 

io.WriteString (■ for output!\n'); 

28 

HALT (20); 

29 

END; (* IF *) 

30 

LOOP 

31 

IF NOT fs.ReadChar (In, Chr) THEN 

EXIT END; 

32 

IF Chr = ’r’ THEN Chr := *1• END; 

33 

IF Chr = ’R’ THEN Chr := ’L’ END; 

34 

IF NOT fs.WriteChar (Out, Chr) THEN 

EXIT END; 

35: 

END; 

36: 

IF (In.Status # fs.eof) OR 
(Out.Status # fs.ok) THEN 

37: 

io.WriteString ('Error Processing 
file!\n'); 

38: 

END; 

39: 

IF NOT fs.Close (In) THEN 
io.WriteString ('Close failed!?\n") 

40: 

END; 

41: 

IF NOT fs.Close (Out) THEN 
io.WriteString ('Close failed!?\n') 

42: 

END; 

41: 

END China. © 1993 M&T 

Listing 14: China.mod benutzt u.a. 

Funktionen des Ein- und Ausgabe- 

moduls FileSystem 
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Mit der Top-Qualität des kanadischen Software-Profis kann sich nun jeder Amiga-Fan den Einstieg in 
professionelle Anwendungen leisten. Zur Bestellung verwenden Sie bitte den Coupon. Wir liefern, 

solange Vorrat reicht. 
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PROFESSIONAL PAGE 3.0 

Das High-End-DTP-Programrr. für den 
AMIGA • Mit sieben Vektor-Fonts und 
Hot-Link-Schnittstelle zu Professional 
Draw • Schriftgröße bis 720 Punkt • 
unterstützt die Farbstandards RGB, 
Euroskala, Pantone • 330 ARexx-Be- 
fehle für intelligente Makros, z.B. zum 
automatischen Generieren von gan¬ 
zen Dokumenten und für Mailmerge-Funktionen • unterstützt sämtliche 
Druckertypen, PostScript und Satzbelichter • benötigt 2 MByte Speicher 

PROFESSIONAL CALC 

Tabellenkalkulation mit Geschäfts¬ 
grafik und integrierter Datenbank • 
berechnet bis zu 65536 Spalten mal 
65536 Zeilen • über 125 statistische, 
trigonometrische, finanzmathema¬ 
tische sowie frei definierbare Funk¬ 
tionen • 75 ARexx-Befehle. u.a. zum 
externen Berechnen • professionelle 
Charts in 2D oder 3D • Schnittstelle zu Lotus, dBase, ProDraw und ASCII 
• unterstützt sämtliche Druckertypen. PostScript und Satzbelichter • 
benötigt 1 MByte Speicher 
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Laut AMIGA-Magazin 10/92 "Das beste 
Zeichenprogramm für den AMIGA" 
(10,5 von 12 Punkten) • Vektororien¬ 
tiertes Zeichnen mit bis zu einer Mill. 
H Farben • mit 300 ARexx-Befehlen frei 
A programmierbar • Import von 24-Bit- 

»j Rastergrafiken • über 140 Clip-Arts im 

fl Lieferumfang • Top-Zeichenfunktio¬ 

nen, z.B. Metamorphose, Verzerren und Rundsatz • unterstützt sämtliche 
Druckertypen, PostScript und Satzbelichter • benötigt 2 MByte Speicher 


VIDEO DIRECTOR 

das Video-Editier-System für jeden 
AMIGA-Fan mit Kamera und Video- 
, M „recorder • Genlock-Unterstützung zum 
Einblenden von Titeln und Grafik • 
intuitive Oberfläche • Audio-Steuerung 
"per Zuruf" • verwaltet einzelne Film¬ 
szenen in beliebiger Kombination • 
mitgelieferte Hardware steuert alle 
Kameras mit LANC/Control L-Schnittstelle. den Panasonic AG-1960 und 
den NEC PC-VCR sowie alle Videorecorder direkt an. in Zweifelsfällen 
auch manueller Betrieb möglich • benötigt 512 KByte Speicher 
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Die neueste Attraktion aus Kanada: 

PAGE SETTER III 

Das integrierte Layoutprogramm 
mit Textverarbeitung, Recht¬ 
schreibungsprüfung und Top- n l H J A A 
Malprogramm bis zu 256 Farben ] M 1 U A ■ 
zum Sensationspreis von U IVI I \J U j 

Sichern Sie sich sofort die neueste 
Version. Updates auf Anfrage. 


BESTELLCOUPON 


Hiermit bestelle ich die Produkte 

■ Professional Page 3.0 

■ Professional Draw 3.0 

■ Professional Calc 

■ Video Director 

■ Page Setter lll 

zum Gesamtpreis von DM 
Da der Bestellwert über 500 DM liegt, ziehe ich davon 
nochmals 3 % ab 
und bezahle insgesamt DM 

■ Emen V-Scheck über den Betrag habe ich beigefügt 

■ Bitte liefern Sie mir die Ware per Nachnahme 


Bitte ausfüllen und senden an: 

IPV • Ippen & Pretzsch Verlags GmbH, Pressehaus, 
Bayerstraße 5, 8000 München 2. Tel. 089/854 24 12. 
Fax 089 / 854 58 37. Hotline jeden Montag von 16.00 - 
18.00 unter 089/854 24 12 
Absender 
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Eine Variable läßt sich mit Hilfe des 
»Typeguards« auch ohne WITH erweitern. 
Schreibt man 

KaufFeld(Kaeuflieh).gekauft 

wird »Kauffeld« so behandelt, als sei es vom 
Typ »Kaeuflich«. 

Innerhalb der »Init«-Prozeduren wird mit 
»NEW« der notwendige Speicher besorgt. 
Hat ein Zeiger nach NEW den Wert »NIL«, 
ließ sich der Speicher nicht reservieren (mög¬ 
licherweise zu wenig vorhanden). An dieser 
Stelle bricht das Programm mit einem Fehler 
ab (»HALT«). NIL als Zeigerinhalt bedeutet, 
daß der Zeiger auf keinen Speicherbereich 
zeigt, also unbenutzt ist. 

Im übrigen ist nach jedem Versuch, Spei¬ 
cher zu allokieren, eine entsprechende Über¬ 
prüfung vorzunehmen. Im schlimmsten Fall 
(der Speicher ließ sich nicht reservieren) 
kann es passieren, daß Sie in einen Speicher¬ 
bereich schreiben, der z.B. von anderen Pro¬ 
grammen benötigt wird. 

Wie man auf Elemente eines Records über 
einen Zeiger zugreift, wissen Sie bereits: ein 
einfacher ».« genügt. Möchte man jedoch alle 
Elemente einer Variablen erreichen, ist der 
» A «-Operator zu verwenden. Um den Inhalt 
bzw. die Daten, auf die der Zeiger zeigt, zu 
kopieren, schreibt man: 

(1) Zeiger2 A := Zeigerl A ; 

Dabei ist zu beachten, daß Zeiger 2 schon 
auf etwas zeigen muß, also zuvor z.B. mit 
»NEW« eingerichtet wurde. (1) kopiert nun 
die Daten, auf die Zeiger 1 zeigt. Ändert man 
Elemente von Zeiger 2, hat dies keinen Ein¬ 
fluß auf die Daten von Zeiger 1. 

Anders verhält es sich bei 

(2) Zeiger2 := Zeigerl; 


Hier wird lediglich die Adresse, nicht der 
Inhalt der Daten kopiert. Ändert man den 
Inhalt über Zeiger 2, hat dies direkte Auswir¬ 
kungen auf den Inhalt von Zeiger 1, denn 
beide Zeiger beziehen sich auf die selbe Spei¬ 
cheradresse. Den mit » A « eingeleiteten Vor¬ 
gang bezeichnet man als dereferenzieren, 
denn ein Zeiger stellt eine Referenz bzw. 
einen Verweis auf Daten dar. 

Benötigt man einen Zeiger nicht mehr, 
kann, nein muß man, den zuvor allokierten 
Speicher mit »DISPOSE« freigeben. Dabei 
ist unbedingt zu beachten, daß alle Zeiger, 
die auf diese Adresse zeigen, einen Undefi¬ 
nierten Inhalt haben. Mit 
DISPOSE (Zeigerl); 

läßt sich Zeiger 2 aus (1) weiterhin beden¬ 
kenlos verwenden, der in (2) zugewiesene 
Zeiger 2 ist jedoch ungültig. 

Zeiger-Arithmetik 
ist auch bei Oberon 
unumgänglich 

Doch auch des Guten zuviel ist möglich: Gibt 
man einen Speicherbereich zweimal mit Dis¬ 
pose frei, läßt der Guru grüßen. 

Ein wichtiges Einsatzgebiet für Zeiger sind 
dynamische Listen. Denken Sie an einen 
Texteditor: Beim Programmstart ist nicht 
ersichtlich, wieviele Zeilen benötigt werden. 
Legt man also z.B. ein statisches Array mit 
1024 Zeilen und 256 Spalten an, werden 
sofort 256 KByte Speicher belegt. Nun kann 
es aber sein, daß nur 20 Zeilen oder weniger 


notwendig sind. Oder andersherum: vielleicht 
sind 1024 Zeilen sogar zu wenig? 

Ein Ausweg aus diesem Dilemma sind Li¬ 
sten. Darunter ist eine Verkettung gleicher 
Elemente (Strukturen) zu verstehen. Bei einer 
Liste existiert immer ein Kopf (Head) und ein 
Ende (Tail). Besteht die Liste nur aus einem 
Element, ist der Kopf gleich dem Ende. 
Ansonsten verweist der Kopf auf das nächste 
Glied, dieses auf ein weiteres usw. Mit Hilfe 
von Zeigern kann man sich so von Glied zu 
Glied durchhangeln, bis man irgendwann das 
Ende der Liste erreicht. Dieses zeigt dann im 
allgemeinen auf NIL. Um die Verwaltung 
solcher Listen zu vereinfachen, stellt der 
Oberon-Compiler das »Lists«-Modul zur 
Verfügung. Mit Hilfe der darin befindlichen 
Prozeduren läßt sich u.a. eine Zeile so anle- 
gen (ein Blick in das Modul erleichtert das 
Verständnis ungemein): 

IMPORT Lists; 

TYPE 

Zeile = RECORD (Lists.Node) 

Str: ARRAY 256 0F CHAR; 

END; 

ZeilePtr = POINTER TO Zeile; 

VAR 

Liste: Lists.List; 

Das Schöne ist, daß man weiterhin pro¬ 
blemlos die Prozeduren aus »Lists« verwen¬ 
den kann, da »Zeile« eine Erweiterung von 
»Node« ist. Je nach Bedarf läßt sich so Spei¬ 
cher für eine Zeile anfordem (»NEW«). Das 
erzeugte Element wird so in die Liste einge¬ 
fügt (»AddHead«, »AddTail«, »AddBefore«, 
»AddBehind«). Möchte man ein Glied der 
Kette löschen, reicht ein Aufruf der Funktion 
»Remove« mit anschließendem »DISPOSE«, 


1: MODULE MiniPaint; 

2: IMPORT 

3: I: Intuition, rq: Requests, s: SYSTEM, d: Dos, e: Exec, 

g: Graphics; 

4: CONST 

5: Version = "$VER: MiniPaint 1.00 (10-Jul-91)\n\r*? 

6: (‘Für den Version-Befehl von OS 2.0 ! Example: 

"Version MiniPaint" *) 

7: VAR 

8: nw: I.NewWindow; 

9: Win: I.WindowPtr; 

10: IMsg: I.IntuiMessagePtr; 

11: Draw, Quit: BOOLEAN; 

12: Class: LONGSET; 

13: Code: INTEGER; 

14: OldX, OldY, X, Y, Color: INTEGER; 

15: PROCEDURE Cut (VAR i: INTEGER; Min, Max: INTEGER); 

16: BEGIN 

17: IF i < Min THEN i := Min END; 

18: IF i > Max THEN i := Max END; 

19: END Cut; 

20: BEGIN 

21: Draw := FALSE; Quit := FALSE; Color := 1; 

22: nw := I.NewWindow (100, 75, 300, 100, 0, 1, 

LONGSET (I.mouseButtons, 

23: I.mouseMove, I.closeWindow}, 

LONGSET (I.rmbTrap, 

24: I.reportMouse, I.windowDrag, I.sizeBRight, I.activate, 

25: I.windowSizing, I.windowDepth, I.windowClose}, 

26: NIL, NIL, s.ADR ("MiniPaint vl.00"), NIL, 

27: NIL, 150, 50, -1, -1, SET (I.wbenchScreen)); 

28: Win := I.OpenWindow (nw); 

29: rq.Assert (Win # NIL, "Sorry, no Window"); 

30: g.SetDrMd (Win A .rPort, g.jaml); 

31: g.SetAPen (Win A .rPort, Color); 

32: REPEAT 

33: e.WaitPort (Win A .userPort); 

34: LOOP 

35: IMsg := e.GetMsg (Win A .userPort); 

36: IF IMsg = NIL THEN EXIT END? 

37: Class := IMsg A .class; 


38: Code := IMsg A .code; 

39: X := IMsg A .mouseX; 

40: Cut (X, Win A .borderLeft+1, Win A .width-Win A .borderRight-2); 

41: Y := IMsg A .mouseY; 

42: Cut (Y, Win A .borderTop+l, Win A .height-Win A .borderBottom-2); 

43: e.ReplyMsg (IMsg); 

44: IF (I.mouseButtons IN Class) THEN 

45: CASE Code OF 

46: | I.selectUp: 

47: Draw := FALSE; 

48: | I.selectDown: 

49: Draw := TRUE; 

50: OldX := X; OldY := Y? 

51: IF g.WritePixel (Win A .rPort, X, Y) THEN END; 

52: g.Move (Win A .rPort, X, Y); 

53: I I.menuüp: 

54: INC (Color); 

55: IF Color > ASH (1, Win A .wScreen A .bitMap.depth)-1 THEN 

56: Color := 0; 

57: END; (‘ IF *) 

58: g.SetAPen (Win A .rPort, Color); (* Farbe einstellen *) 

59: ELSE 

60: END; (* CASE *) 

61: ELSIF (I.mouseMove IN Class) THEN 

62: IF ((OldX # X) OR (OldY # Y)) AND Draw THEN 

63: OldX := X; OldY := Y; (‘Um nicht 1 Pixel lange 

Linien zu zeichnen *) 

64: g.Draw (Win A .rPort, X, Y); 

65: END; (* IF *) 

66: ELSIF (I.closeWindow IN Class) THEN 

67: Quit := TRUE; (* und tschüß! *) 

68: END; (* IF *) 

69: END; (‘ LOOP *) 

70: UNTIL Quit; 

71: CLOSE 

72: IF Win # NIL THEN I.closeWindow (Win); Win := NIL END; 

73: END MiniPaint. © 1993 M&T 

Listing 15: MiniPaint.mod zeigt die Betriebssystempro¬ 
grammierung mit Oberon 
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um den von diesem Element benötigten Spei¬ 
cher dem System zurückzugeben. 

Wie schon erwähnt: in C ist die Pointer- 
Arithmetik nicht immer einfach, da sich 
schnell Fehler einschleichen, die der Compi¬ 
ler nicht moniert. Obwohl der Oberon-Com¬ 
piler hier weitaus bessere Überprüfungen 
vornimmt, ist ein wenig Vorsicht angebracht. 
Es empfiehlt sich daher das Importieren des 
»NoGuru«-Moduls, um eventuelle Laufzeit¬ 
fehler und deren Art erkennen zu können. 

Module 

Auch wir sind in der Lage, eigene Module 
zu schreiben und diese von anderen importie¬ 
ren zu lassen. Der grundlegende Aufbau 
eines Moduls ist bekannt. Was wir Ihnen bis¬ 
lang vorenthalten haben, ist die Möglichkeit, 
Bezeichner zu exportieren und der 
»CLOSE«-Teil. 

Wir wissen, daß beim Aufruf eines Moduls 
der BEGIN-Teil ausgeführt wird. Der 
CLOSE-Teil wird vollzogen, wenn das 
Modul endet. Der große Vorteil von CLOSE 
liegt darin, daß dieser Teil auch dann abgear¬ 
beitet wird, wenn ein Laufzeitfehler auftritt 
oder der Abbruch mit <Ctrl C> (hierzu ist das 
Modul »Break« zu importieren) erzwungen 
wird. Das ermöglicht es, auch im Notfall 
noch alle zuvor angelegten Ressourcen frei¬ 
zugeben. 

Nicht weniger bedeutungsvoll aber ist es, 
die im Modul existierenden Prozeduren, Va¬ 
riablen usw. für andere Module sicht- und 
nutzbar zu machen. Möchten Sie beispiels¬ 
weise ein Programm schreiben, das IFF-Bil- 
der anzeigt, wäre es praktisch, dieses Projekt 
in zwei Module zu unterteilen. Ein Modul 
kümmert sich um die Parameter, die das Pro¬ 
gramm übers CLI/Shell oder die Workbench 
erhält, das andere ist auf die Bearbeitung der 
IFF-Bilder spezialisiert und stellt Prozeduren 
zum Laden oder Speichern zur Verfügung. 

Besonderes 
Augenmerk gilt 
den Modulen 

Vorteil einer solchen Einteilung ist, daß 
das IFF-Modul auch von anderen Program¬ 
men zu verwenden ist und die Routinen nicht 
ständig neu programmiert werden müssen. 

Möglich wird das durch die Exportmarkie¬ 
rung »*«. Mit ihr lassen sich globale Proze¬ 
duren, Variablen etc. exportieren. So können 
fremde Module auf diese zurückgreifen. Das 
fremde Modul muß lediglich das »Service«- 
Modul importieren. Beim Importieren wird 
der BEGIN-Teil des Moduls ausgeführt. Ist 
das Hauptmodul beendet, ruft Oberon die 
CLOSE-Teile der importierten Module in 
umgekehrter Reihenfolge auf. Jedes Modul 
kann für sich somit definierte Ausgangsbe¬ 
dingungen schaffen und bei Beendigung 
eventuell angeforderte Ressourcen zurückge¬ 
ben. Bei Bedarf eröffnet das io-Modul im 


BEGIN-Teil beispielsweise ein Fenster, das 
im CLOSE-Teil geschlossen wird. 

Als Beispiel zur Verwendung der Export¬ 
markierung dient wiederum das io-Modul. 
Betrachten Sie sich hierzu den auf der Com¬ 
piler-Diskette befindlichen Quelltext. »*« 
folgt immer dem Namen einer Prozedur, 
Variablen usw.: 

MODULE MeinModul; 

TYPE 

Zeile*: ARRAY 80 OF CHAR; 

VAR AllesKlar*: BOOLEAN; 

Intern: INTEGER; 

Text: Zeile; 

PROCEDURE Hallo* (a: SET); 

BEGIN 

{* ... *) 

END Hallo; 

BEGIN 

AllesKlar := TRUE; 

CLOSE 

AllesKlar := FALSE; 

END MeinModul. 

Der Typ »Zeile«, die Variable »AllesKlar« 
und die Prozedur »Hallo« ist somit von ande¬ 
ren Modulen ansprechbar. In fremden Modu¬ 
len schreibt man: 

IMPORT mm: MeinModul; 

Anschließend kann man wie gewohnt 
»mm.Zeile« als Typ verwenden oder die Pro¬ 
zedur »mm.Hallo« aufrufen. 

Eine Besonderheit sind Records. Hier las¬ 
sen sich einzelne Elemente exportieren, 
andere wiederum nicht. So gesehen ist es 
möglich, fremde Module an einem Zugriff 
auf Elemente, die sie nichts angehen, zu hin¬ 
dern (information hiding). Ein Beispiel: 

VAR Demo*: RECORD 

text*: ARRAY 10 OF CHAR; 
intern: INTEGER; 
aha*: SET; 

END; 

Module, die den Record »Demo« importie¬ 
ren, können nur auf die Elemente »text« und 
»aha« zugreifen, »intern« ist tabu. 

Beim Erstellen eigener Module ist unbe¬ 
dingt darauf zu achten, sie voneinander weit¬ 
gehend unabhängig zu gestalten: Jedes 
Modul sollte auch in einer anderen Umge¬ 
bung einwandfrei laufen. Mit diesem Vorsatz 
läßt sich viel Arbeit bei der Fehlersuche und 
Erweiterung bestehender Module einsparen. 
Es ist zu vermeiden, globale Variablen frem¬ 
der Module zu modifizieren bzw. von diesen 
abhängig zu sein. 

Weitere Oberon-Module 

Bis jetzt haben wir hauptsächlich das 
Modul io verwendet. Ein weiteres, nicht 
weniger wichtiges ist »Break«. Wird es 
importiert, ist es möglich, das Programm mit 
<Ctrl C> abzubrechen, und zwar beim Aufruf 
von Prozeduren mit eingeschalteter Stack- 
Überprüfung. Soll innerhalb einer Schleife 
ohne Prozeduraufrufe auf Abbruch getestet 
werden, ist die Funktion »CheckBreak« in¬ 
nerhalb der Schleife anzuspringen. 

Wichtig sind zudem die beiden »NoGuru«- 
Module. Importiert man sie, bricht das Pro¬ 


gramm bei einem Laufzeitfehler nicht nur ab, 
sondern gibt zudem die Fehlerursache aus. 

Um die Parameterübergabe an Programme 
zu vereinfachen, behilft man sich mit dem 
Modul »Arguments«, dessen Benutzung im 
Listing 13, »ArgDemo.mod«, demonstriert 
wird. Das Programm gibt alle Argumente 
numeriert auf dem Bildschirm aus. Starten 
Sie »ArgDemo« sowohl vom CLI/Shell als 
auch von der Workbench. »NumArgs« infor¬ 
miert über die Anzahl angegebener Argu¬ 
mente. Sind sie Null, hat man im CLI/Shell 
entweder keine Argumente angegeben, oder 
das Programm von der Workbench ohne wei¬ 
tere Icons aufgerufen. »GetArg« liefert das 
gewünschte Argument. Übergibt man als 
Parameter Null, erfährt man den Namen des 
Programms. Mit »GetLock« erhält man einen 
Lock auf das Verzeichnis. 

Auch »FileSystem« ist ein zentrales 
Modul, worüber sich die Dateiverwaltung 
abwickeln läßt. »China.mod« (Listing 14) 
verwendet die Module »Arguments«, »File- 
System« und »io«. 

Spielen wir jetzt eine der Stärken von 
Amiga-Oberon aus: Die Programmierung des 
Amiga-Betriebssystems. Ein einfacher, aber 
oft benötigter Betriebssystemaufruf ist der 
zum Öffnen eines Fensters. Sicherlich wissen 
auch Sie, daß das Amiga-Betriebssystem in 
Libraries unterteilt ist: Jede ist für einen 
bestimmten Aufgabenbereich zuständig. 

Um ein Window (Fenster) zu öffnen, 
benötigt man die »intuition.library«. Um das 
Öffnen und Schließen müssen wir uns im 
Unterschied zu einigen anderen Sprachen 
nicht kümmern. Dies geschieht automatisch 
im BEGIN-Teil des Interface-Moduls »Intui¬ 
tion. mod«. Im CLOSE-Teil wird die Library 
selbstverständlich wieder geschlossen. Man 
muß also nur das zugehörige Interface-Modul 
importieren, und schon kann man alle Funk¬ 
tionen der Library verwenden. 

Beginnen wir mit der »OpenWindow«- 
Funktion. Betrachtet man sich das entspre¬ 
chende Interface-Modul oder liest man in der 
Bibel des Amiga-Programmierers nach (den 
ROM Kernel Reference Manuals [4], kurz 
RKMs), benötigt OpenWindow() als Parame¬ 
ter einen Record vom Typ »NewWindow«. 
Dessen Elemente muß man vor dem Open- 
Window-Aufruf mit sinnvollen Weiten bele¬ 
gen. Die Funktion liefert einen Zeiger auf die 
Window-Struktur, sozusagen den Schlüssel. 
Die Bedeutung der jeweiligen Elemente ist 
dem Kasten zu entnehmen. Möchte man das 
Amiga-Betriebssystem programmieren, was 
zwangsläufig nicht ausbleiben wird, ist die 
Anschaffung der RKMs erforderlich. 

Listing 15 (»MiniPaint.mod«) demonstriert 
das Öffnen eines einfachen Fensters. Die 
Belegung der NewWindow-Struktur erfolgt 
mit strukturierten Konstanten. Mit »Open- 
Window« öffnen wir es schließlich. Die Pro¬ 
zedur »Assert« des »Requests«-Moduls stellt 
sicher, daß das Fenster auch wirklich offen 
ist. Ist der Zeiger »Win« gleich NIL (Undefi¬ 
niert), gab's irgendwo Probleme. Mit »Set- 
DrMd« legen wir den Zeichenmodus fest. 
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New Window-Flags für Oberon 


leftEdge, topEdge, width, height: INTEGER; 

Diese Werte geben die Abmessungen des Fensters an. Es ist darauf zu ach¬ 
ten, daß sich das ganze Window innerhalb des Screens befindet. 


detailPen, blockPen: SHORTINT; 

Zeichenfarben, die für Titelzeile, Rahmen und Gadgets verwendet werden. 
Sollte man auf 0 und 1 setzen. 


idcmpFlags: LONGSET; 

Diese Flags geben an, welche Ereignisse dem Programm, zu dem das Win¬ 
dow gehört, gemeldet werden. 

sizeVerify; Intuition möchte die Größe des Fensters ändern. Man sollte 
kritische Ausgaben hinter sich bringen und die Message schnellstens 
beantworten. 

newSize; Die Größe des Fensters wurde verändert. 
refreshWindow: Das Fenster muß restauriert werden, da es zwischenzeit¬ 
lich überdeckt war. 

niouseButton: Eine Maustaste wurde gedrückt. Welche, erfährt man 
durchs »code«-Feld der »IntuiMessage«. 

mouseMove: Die Maus wurde bewegt. Die neuen Koordinaten findet man 
ebenfalls in der »IntuiMessage«. 

gadgetDown: Ein Gadget wurde aktiviert. Einen Zeiger darauf findet man 
im Element »iAddress« der »IntuiMessage«. 
gadgetUp: Ein Gadget wurde losgelassen. 
reqSet: Ein Requester wurde im Fenster geöffnet. 
menuPick: Ein Menüpunkt wurde ausgewählt, 
closeWindow: Das Close-Gadget des Fensters wurde betätigt. 
rawKey: Eine Taste wurde gedrückt oder losgelassen. Im code-Feld der 
Intuition-Message findet man Code der betätigten Taste. Sondertasten las¬ 
sen sich so hervorragend abfragen. 
reqVerify: Intuition möchte einen Requester öffnen. 
reqClear: Ein Requester wurde geschlossen. 
menuVerify: Intuition möchte ein Menü darstellen. 
newPrefs: Die Preferences (Voreinstellungen) wurden modifiziert, 
disklnserted, diskRemoved: Eine Diskette wurde eingelegt bzw. entfernt. 
wbenchMessage: Dient der systemintemen Verwendung. Nicht benutzen! 
activeWindow: Window wurde aktiviert bzw. deaktiviert. 
deltaMove: Ähnlich wie »mouseMove«, allerdings bekommt man hier 
nicht absolute Koordinaten, sondern die Änderung im Vergleich zur vori¬ 
gen Position. 

vanillaKey: Im Unterschied zu »rawKey« findet man im code-Feld den 
ASCII-Wert der Taste. 

intuiTicks: Ist das Fenster aktiv, erhält man sie alle 1/50 Sekunde. 
idcmpUpdate: Existiert erst ab Betriebssystem-Version 2.0 und wird für 
Boopsi-Gadgets benötigt. 

menuHelp: Help-Taste wurde während der Menüauswahl gedrückt. Die¬ 
ses Flag gibt's ebenfalls erst ab Betriebssystem-Version 2.0. 
changeWindow: Neu ab OS 2.0: Position oder Größe des Fensters wurde 
verändert. 

lonelyMessage; Systemintefn. Nicht verwenden! 


flags: LONGSET; 

Hier gibt man die Eigenschaften des Fensters an. 
windowSizing: Das Fenster läßt sich in seinen Ausmaßen vom Anwender 
verändern. Die Größenveränderung wird gemeldet, wenn man das 
IDCMP-Flag »newSize« setzt. 
windowDrag: Das Window kann verschoben werden, 
window Depth: Das Window hat ein Gadget (OS 2.0 oder höher) oder 
Gadgets (OS 1.3 oder niedriger), um es in den Vorder- bzw. Hintergrund 
zu klicken. 

windowClose: Das Fenster verfügt über ein Schließsymbol in der linken 
oberen Ecke. Man sollte das IDCMP-Flag »closeWindow« setzen, damit 
man erfahrt, wann das Schließsymbol betätigt wurde. 
sizeBRight: Dieses Flag hat nur Sinn in Verbindung mit »windowSizing«. 
Der rechte Rahmen über dem Size-Gadget wird verbreitert. 


sizeBBottom: Ähnlich wie »sizeBRight«, hier wird der untere Rand ver¬ 
wendet. 

simpleRefresh: Wird das Fenster überlagert, ist der Inhalt zerstört. Ist 
simpleRefresh« gesetzt, restauriert Intuition das Fenster nicht, sondern 
man ist selbst dafür verantwortlich. Nützlich ist hierbei das zugehörige 
IDCMP-Flag. 

superBitMap: Übergroße BitMap. Mehr dazu in den RKMs. 
backDrop: Das Fenster liegt immer hinter allen anderen. Sollte man nur 
auf eigenen Screens verwenden. Sinnvoll nur in Verbindung mit »bor¬ 
derless« (s.u.). 

reportMouse: Man möchte immer über die Mausposition informiert 
werden. Zusätzlich ist das IDCMP-Flag »mouseMove« zu setzen. 
gimmeZeroZero: Bitte nicht verwenden, wenn's nicht unbedingt sein 
muß. Verhindert das Zeichnen in den Window-Rahmen. Das so durchge¬ 
führte Clipping sollte man selbst vornehmen, da GZZ-Windows extrem 
langsam sind. 

borderless: Das Fenster besitzt keinen Rahmen. Nur auf eigenen 
Screens in Verbindung mit »backDrop« (siehe oben) sinnvoll, 
activate: Nach dem Öffnen des Fensters wird es aktiv. 
windowActive, inRequest, menuState: Diese Flags werden vom Sy¬ 
stem verwaltet. Sie signalisieren den momentanen Zustand des Fensters. 
rmbTrap: Beim Betätigen der rechten Maustaste wird keine Menüzeile 
dargestellt. Dieses Flag ist dann notwendig, wenn man mit »mouseBut- 
tons« die rechte Maustaste abfragen will. Sinnvoll auch dann, falls das 
Fenster über kein Menü verfügt. 

noCareRefresh: Kümmert man sich selbst um den Refresh des Win¬ 
dows, wird man mit diesem Flag von der Pflicht enthoben, »BeginRe- 
fresh« und »EndRefresh« aufzurufen. 
windowRefresh: Das Window wird gerade erneuert, 
wbenchWindow: Das Fenster wird auf der Workbench geöffnet. 
windowTicked: Internes Flag, nur ein »Tick« pro 1/50 Sekunde 
nwExtended: Es handelt sich um eine erweiterte New Window-Struktur. 
Das Flag ist wichtig, wenn man unterm OS 2.0 mit Tag-Listen arbeitet, 
visitor: Wird unter OS 2.0 von Intuition gesetzt und zeigt an. daß es sich 
um einen Besucher-Window auf einem fremden Screen handelt, 
zoomed: Das Window ist gerade im alternativen Größenzustand. 
hasZoom: Das Window besitzt ein Zoom-Gadget (nur unter OS 2.0 und 
höher). Das Flag setzt Intuition. 


firstGadget: GadgetPtr; 

Zeiger aufs erste eigene Gadget des Fensters. Ist kein eigenes Gadget vor¬ 
handen, sollte man hier NIL eintragen. 


checkMark: ImagePtr; 

Hier kann man den Menü-Häkchen ein besonderes Aussehen verleihen. 
Gewöhnlich trägt man hier NIL ein. 


title: e.STRPTR; 

Hier gibt man die Adresse des Fenstertitels an. Die Adresse eines Strings 
erhält man mit Hilfe der Funktion »ADR« des »SYSTEM«-Moduls. 


screen: ScreenPtr; 

Hier tragen wir den Screen-Pointer ein, auf dem das Fenster geöffnet wer¬ 
den soll. Ist es der Workbench-Schirm, genügt NIL. 


bitMap: g.BitMapPtr; 

Hat man ein Fenster mit übergroßen Ausmaßen, in dem gescrollt wird, 
trägt man hier den Zeiger auf die Bitmap ein. Sonst NIL. 


minWidth, minHeight, maxWidth, maxHeight: INTEGER; 

Falls sich ein Sizing-Gadget am Fenster befindet, ist es ratsam, hier die 
minimalen und maximalen Fensterausmaße anzugeben. Trägt man bei den 
Max-Werten -1 ein, darf das Fenster beliebig groß sein. 


type: SET; 

Typ des Bildschirms, auf dem das Fenster erscheinen soll. Normalerweise 
ist dies der Workbench-Screen (»SET {I.wbenchScreen}«). 


Der nun folgende Programmteil ist eine 
Schleife, die erst dann beendet wird, wenn 
die boolesche Variable »Quit« wahr ist. Mit 
»WaitPort« warten wir darauf, daß Intuition 
eine Nachricht für uns hat. Diese lesen wir 
mit »LOOP« und »GetMsg« aus. 

Die Prozedur »Cut« modifiziert die Maus¬ 
koordinaten insofern, daß sie innerhalb der 
Fensterbegrenzung liegen und den Rahmen 


nicht überschreiben. Mit der linken Mausta¬ 
ste kann man Linien zeichnen. Dazu benöti¬ 
gen wir die Funktionen »Move«, »Draw« und 
»WritePixel« aus der Graphics-Library (siehe 
Importliste). Ein Druck auf die rechte Maus¬ 
taste wechselt die Farbe. Mit »ASH« berech¬ 
nen wir die Farbanzahl des Bildschirms. Im 
Close-Teil wird das Fenster wieder geschlos¬ 
sen. 


Nun wünschen wir Ihnen viel Spaß mit der 
Programmiersprache Oberon. rz 
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Doppel-Plus 

Amiga-C++ 

Auf der Kölner Amiga-Messe '92 gab's eine neue Programmiersprache 
zu bestaunen: »Maxon C++«. Was verbirgt sich hinter C ++, was 
bringt es und wer braucht es? Wo liegen die Unterschiede zu Ansi-C? 


von Jens Gel har 

D ie Programmiersprache C ist vielen 
geläufig. Was bedeuten aber die zwei 
»++«? Bei C++ handelt es sich um das 
weiterentwickelte Ansi-C. Es besitzt die her¬ 
vorstechende Eigenschaft, objektorientierte 
Programmierung zu unterstützen (OOP). Der 
Begriff ist z.Zt. in aller Munde, dennoch ist 
er erklärungsbedürftig. 

Der objektorientierte Ansatz 

Nahezu alle in der Praxis anzutreffenden 
Hochsprachen sind prozedural: Ein Pro¬ 
gramm ist in erster Linie eine Aneinanderrei¬ 
hung von Anweisungen. Daneben gibt's funk¬ 
tionale Programmiersprachen, deren grundle¬ 
gendes Konzept das der Funktion ist (z.B. 
LISP). Eine weitere Spezies sind die in der 
Praxis wenig verbreiteten logischen Program¬ 
miersprachen (z.B. PROLOG), bei denen ein 
Programm die Beschreibung des Problems in 
Form logischer Ausdrücke darstellt. Näheres 
hierzu und zu Programmiersprachen im allge¬ 
meinen finden Sie in [ 1 ]. 

Der objektorientierte Ansatz ist ein neues 
Konzept, das die Daten eines Programms, 
also die eigentlichen »Objekte«, in den Vor¬ 
dergrund stellt. Der Programmierer ist also 
nicht mehr primär mit der für das prozedurale 
Konzept typischen Frage »Was soll mein 
Programm auf welche Weise machen?« kon¬ 
frontiert, sondern überlegt zunächst, welche 
Datenobjekte das Programm benötigt und 
welche Eigenschaften diese haben. 

Letzten Endes sind diese Objekte nichts 
anderes als Datenstrukturen, also das, was 
man in Pascal als »Record« oder in C als 
»struct« bezeichnet. Diesbezüglich hat also 
ein Objekt auch so etwas wie einen Datenty¬ 
pen. Da neben einer Ansammlung von Daten 
allerdings noch mehr gehört, redet man hier 
nicht von »Typen«, sondern von »Klassen«. 
In einer Klasse findet man zusätzliche Funk¬ 
tionen, die ihre Eigenschaften beschreiben. 

Dazu ein fast schon klassisches Beispiel: 
Möchte man eine verkettete Datenliste imple¬ 
mentieren, definiert man sich in einer proze- 
duralen Programmiersprache einen Datenty¬ 
pen, den man z.B. »Liste« nennt. Dazu 
gehören natürlich auch spezielle Funktionen, 
z.B. »Insert« zum Einfügen eines neuen 
Listenelements. Ein typischer Aufruf: 

Insert(Liste, Neues Element). 


In einer objektorientierten Programmier¬ 
sprache - neben C++ sind »Simula«, »Small¬ 
talk« und »Objective C« prominente Mitglie¬ 
der dieser Familie - wird das Ganze differen¬ 
ziert gehandhabt. Hier wird man die Funktion 
»Insert« als eine Eigenschaft der Klasse Liste 
deklarieren, und man ruft sie z.B. mit 
Liste.Insert(Neues Element) 
auf. Verfechter der reinen Lehre objektorien¬ 
tierter Programmierung bezeichnen das dann 
nicht mehr als einen Funktionsaufruf, son¬ 
dern sagen, hier werde die Methode »Insert« 
aufs Objekt »Liste« angewandt. Einfacher ist 
folgende Interpretation: Egal, was sich hinter 
dem Objekt »Liste« verbirgt - das Objekt hat 
die Operation Insert() auszuführen. In Small¬ 
talk würde man sogar davon sprechen, daß an 
»Liste« die Nachricht »Insert (Neues Ele¬ 
ment)« geschickt wurde. 

Auf den ersten Blick ist das zugegebener¬ 
maßen ein mäßig spektakulärer Unterschied 
in der Schreibweise, verbünden mit einer 
leicht esoterisch-verquast anmutenden Art, 
einen Programmtext zu deuten, zumal man 
die Insert-Funktion immer noch selbst schrei¬ 
ben muß und die so viel anders nicht aussieht 
als die einer prozeduralen Sprache. Interes¬ 
sant wird es aber, wenn die Programmier¬ 
sprache mächtige Features fürs Definieren, 
Kombinieren und Modifizieren von Klassen 
zur Verfügung stellt. Der wichtigste Begriff 
in diesem Zusammenhang ist das Konzept 
der Vererbung. 

Die Grundidee ist, von einer vorhandenen 
Basisklasse eine neue Klasse abzuleiten, 
indem man unter einem neuen Klassennamen 


Maxon C++ 


Maxon C++ gibt’s in zwei Versionen. Die 
einfache Version setzt sich aus einem Ansi-C 
und C++-Compiler zusammen (in einer inte¬ 
grierten und einer CLI-Version). Enthalten ist 
weiterhin der Programmeditor »Edward«, der 
Oberflächengenerator »MakeAPP« und das 
Online-Hilfe-System »HotHelp«. Der Preis: 
Inklusive einem ca. 800seitigen deutschspra¬ 
chigen Handbuch ca. 400 Mark. 

Die Maxon C++-Developer-Version ist um 
den Source-Level-Debugger und den Macro- 
Assembler erweitert. Preis: ca. 600 Mark. 

Bezugsadresse: 

Maxon Computer GmbH. Schwalbacher Str. 52, W-6236 Esch¬ 
bornes.. Tel. (0 61 96)48 18 II 


Eigenschaften der Basisklasse modifiziert 
und vor allem neue Methoden und Daten hin¬ 
zufügt. Diese Klasse »erbt« dann die Eigen¬ 
schaften ihrer Basisklasse, sofern sie diese 
nicht verändert. In vielen Programmierspra¬ 
chen kann man eine Klasse sogar von mehre¬ 
ren Basen ableiten - so lassen sich Eigen¬ 
schaften von Klassen zusammenfassen. 

Zurück zum Beispiel: Insert implementiert 
man objektorientiert eben nicht für eine ganz 
bestimmte Art von Listen (also nur eine 
Klasse), sondern zunächst für ganz allge¬ 
meine Listenstrukturen, von der sich letztlich 
nach Belieben ableiten läßt - z.B. eine sor¬ 
tierte Liste von Zeichenketten, aus der man 
wiederum durch Vererbung eine Adressenli¬ 
ste oder ein Telefonbuch kreiert. 

Wer sich mit dem Amiga-Betriebssystem 
näher befaßt hat, dem dürften solche Kon¬ 
zepte bekannt Vorkommen: Ein zentrales Ele¬ 
ment von »Exec« sind die Datentypen »List« 
und »Node«. Sie finden überall dort Anwen¬ 
dung, wo Listen benötigt werden: Für Task-, 
Libraries- und Message-Listen beispiels¬ 
weise. Definiert sind sie in C und entspre¬ 
chend umständlich und unflexibel ist das 
Ergebnis. 

Vererbung ist ein 
Merkmal objekt¬ 
orientierter Sprachen 

Zur objektorientierten Programmierung 
gehört aber mehr. Ein Objekt muß für 
gewöhnlich initialisiert werden. Hört es auf 
zu existieren, ist das »Aufräumen« fällig, 
also z.B. Ressourcen oder Speicher freigege¬ 
ben. Durch »Konstruktoren« und »Destrukto- 
ren« wird das weitgehend automatisiert, so 
daß der Programmierer hier keinen weiteren 
Denkaufwand investieren muß. Die Daten 
entwickeln also scheinbar ein gewisses 
Eigenleben, was man auch als »lokale Intelli¬ 
genz« bezeichnet. 

Ferner umfassen objektorientierte Spra¬ 
chen gewöhnlich noch Konzepte für die sau¬ 
bere Trennung von Implementation und 
Schnittstelle. Bei der Klasse »Liste« wäre 
z.B. die Funktion/Methode »Insert« von 
außen sicht- und von jedem Teil des Pro¬ 
gramms nutzbar. Implementatorische Details 
wie Pointer, mit denen sich Listenelemente 
verketten lassen, deklariert man vorzugs¬ 
weise als private Daten der Klasse: So sind 
sie ausschließlich für die Funktionen der 
Klasse selbst sichtbar und lassen sich nicht 
von anderen Programmteilen manipulieren. 
Objektorientierte Sprachen wie beispiels¬ 
weise C++ bieten Konzepte, solche Verbote 
penibel zu überwachen. 

Dieser Artikel kann die Vorteile der ob¬ 
jektorientierten Programmierung nicht um¬ 
fassend darstellen oder gar eine Einführung 
in gebräuchliche Konzepte der neuen Art zur 
Programmierung bieten. Die primären Vor¬ 
teile zeichnen sich allerdings schon aus den 
ersten Erklärungen ab: 
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□ Eines der wichtigsten Merkmale ist die 
gesteigerte Übersichtlichkeit des Quelltexts 
insofern, daß man zusammengehörende Da¬ 
ten und Funktionen auch gemeinsam dekla¬ 
riert und eindeutig festlegt, in welchem Pro¬ 
grammteil auf bestimmte Bezeichner zuge¬ 
griffen werden darf. Vor allem letzteres ver¬ 
bessert die Sicherheit und speziell die Wart¬ 
barkeit der Programme. 


len Programmiersprachen gewöhnte Effizienz 
zu erzielen. Außerdem steht man in der rau¬ 
hen Wirklichkeit außerhalb des akademi¬ 
schen Elfenbeinturms vor dem knallharten 
Fakt, daß Millionen Programmierer nicht 
umlernen und dann vielleicht auch noch Un¬ 
mengen vorhandener Quelltexte in eine neue 
Sprache umschreiben wollen - eine ökonomi¬ 
sche Tatsache, an der schon manche interes- 


1: #include <exec/types.h> 

2: #include <dos/dos.h> 

3: #include <clib/exec_protos.h> 

4: Dinclude <rct/rctdef.h> 

5: #include <clib/rct_protos.h> 

6: #include <rct/rcttagfuncs.h> 

7: #include <iostream.h> 

8 : 

9: APTR RctBase, app; 

10: 

11: void main() { 

12 : 

13: if ((RctBase = OpenLibrary ("rct.library\16)) && 

14: (app = R_InitApplTags(TAG_DONE)> { 

15: if( R_FormAlertTags( app, RFA_DefaultID, 1L, RFA_AlertText, 

16: "[Wahlen Sie Ihre Programmiersprache!][C++IANSI-C)", TAG_DONE)) 

17: cout « "Warum nur ANSI-C?*; 

18: eise 

19: cout « "Ihre Entscheidung ist goldrichtig!" 

20: R_ExitAppl(app); 

21: CloseLibrary((Library*)RctBase); 

22 : ) 

23: } © 1993 M&T 


Listing 1: Ein mit Fehlern 
gespicktes Programm und 
Bewährungsprobe für den 
Compiler 


□ Ein weiterer Vorteil ist die Wiederver¬ 
wertbarkeit von Quelltexten. Da es die Pro¬ 
grammiersprache durch mächtige Konzepte 
unterstützt, komplexe Probleme erst ganz all¬ 
gemein zu lösen und diese Teillösung dann 
für konkrete Anwendungen zu spezialisieren, 
muß man das Rad nicht immer wieder neu 
erfinden. Ganze Klassen aus anderen Projek¬ 
ten lassen sich leicht in ein neues Programm 
übernehmen. Tut man das nicht nur im stillen 
Kämmerlein sondern macht die Früchte sei¬ 
ner Arbeit auch anderen Programmierern 
zugänglich, bezeichnet man das als eine 
»Klassenbibliothek«. 

Diese Vorteile machen sich insbesondere 
bei umfangreichen Projekten bemerkbar. Das 
ist unter anderem einer der Gründe, warum 
objektorientierte Programmiersprachen - 
allen voran C++ - im professionellen Bereich 
immer größere Verbreitung finden. 

OOP und C++ 

Im Leben wird einem bekanntlich wenig 
geschenkt, und so muß man auch für die oben 
genannten Features bezahlen, vor allem dann, 
wenn man die »reine Lehre« des objektorien¬ 
tierten Paradigmas verwirklicht sehen will. 
Ein Aufruf einer Methode ist kein simpler 
Funktionsaufruf, denn es muß stets - und 
zwar meist zur Laufzeit des Programms - 
festgestellt werden, zu welcher Klasse ein 
Objekt gehört und was genau deshalb zu tun 
ist. Klar, daß das zu einem gewissen Over- 
head führt, sowohl in der Geschwindigkeit 
des Programms als auch im Speicherbedarf 
der Datenobjekte. 

Das zündete schließlich die Idee, von die¬ 
ser puristischen Form objektorientierter Pro¬ 
grammiersprachen ein wenig abzurücken und 
dafür weniger schöne Programme in Kauf zu 
nehmen - mit dem Erfolg, die von prozedura- 


sante neue Programmiersprache gescheitert 
ist. Es entstand also das Bedürfnis nach einer 
Sprache, die von einem etablierten Sprach- 
standard ausgeht und sie um objektorientierte 
Konzepte erweitert, ohne dabei den ursprüng¬ 
lichen Standard gravierend zu ändern. 

Das Ergebnis war das auf Ansi-C aufge¬ 
setzte C++. Es stellt einen gelungenen Kom¬ 
promiß aus der Schönheit objektorientierter 
Konzepte und der Kraft prozeduraler Spra¬ 
chen dar. Da nur wenige Veränderungen am 
C-Kem von C++ vorgenommen werden, las¬ 
sen sich C-Programme nach meist nur gerin¬ 
gen Modifikationen von einem C++-Compi- 
ler übersetzen. Zudem bieten C++-Übersetzer 
oft Optionen, solche Unstimmigkeiten tole¬ 
ranter zu behandeln, oder sie lassen sich 
gleich in den Ansi-C-Modus umschalten. 

Für den aufstiegswilligen C-Programmie- 
rer ist C++ also die erste Wahl, da er keine 
neue Sprache lernen muß, sondern Schritt für 
Schritt die zusätzlichen Features von C++ 
kennenlernen und ausprobieren kann. 

q-I v .. ,, || jgjna 

m i , t <- _ fl 

I “I“ *xp*ct*d. 9 

i »xptcttd. 


U0RK2:M*T/CflSYdano .epp. Lin* 16. Cot. 2 
“>■ *xp*ct*d. 

APTR Rct Bas*. app; 

^oid n« ln() 

"cout «< “Ihr* Entsch*Iduna lat «oldrichtig!“ 
?Te*»l?Erir!ttiibr»rv»)(lctB«u> ; 
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Bild 1: Editor und Compiler arbeiten 
in der Amiga-C++-Implementation 
Hand in Hand und ermöglichen so 
extrem kurze Entwicklungszeiten 


Goodies und Features 

Beim Entwickeln von C++ hat man nicht 
nur objektorientierte Konzepte zum guten 
alten C hinzugefügt, sondern auch noch eine 
Vielzahl interessanter und nützlicher Features 
aufgenommen, die zudem einiges von dem 
entschärfen, was C nach landläufiger Mei¬ 
nung so berüchtigt gemacht hat. 

Das fängt bei Kleinigkeiten wie einer alter¬ 
nativen Schreibweise für Kommentare an (sie 
beginnen mit »//« und enden am Zeilenende, 
was gegenüber der C-Schreibweise mit »/* ... 
*/« viel Tipperei spart) und hört bei den Ope¬ 
ratoren »new« und »delete«, die die Verwal¬ 
tung dynamischer Datenstrukturen vereinfa¬ 
chen (nie wieder »malloc«) noch lange nicht 
auf: Die etwas restriktivere Typprüfung und 
auch sonst etwas strenger gefaßte Sprachdefi- 
nition wird zwar einige hartgesottene C- 
Coder stören, erspart aber gerade dem Ein¬ 
steiger etliche der Fallgruben, die C dem Pro¬ 
grammierer gräbt. Referenzen machen die 
Arbeit mit Pointern leichter und ermöglichen 
endlich Funktionsparameter mit »Call by 
Reference«. 

Eines der mächtigsten neuen Features aber 
ist die Möglichkeit der Überladung. Zum 
einen darf man Funktionen, vorzugsweise 
natürlich dann, wenn sie ähnliches tun, iden¬ 
tische Namen geben, sofern sich die Parame¬ 
terlisten unterscheiden. Der Compiler erkennt 
dann beim Aufruf einer solchen überladenen 
Funktion anhand der Argumente, welche 
Funktion gemeint ist. Betrachten wir uns ein¬ 
mal die Standard-Bibliotheken von Ansi-C: 
Dort findet man »abs«, »labs« und »fabs«, 
die alle dasselbe tun - nämlich den Betrag 
einer Zahl zu berechnen, und zwar für »int«, 
»long int« und »double«-Zahlen. In C++ 
ließen sich alle drei Funktionen »abs« nen¬ 
nen, was wesentlich ausdrucksstärker und 
intuitiver ist. Der Compiler erledigt den Rest. 

Doch nicht nur Funktionen, auch Operato¬ 
ren wie »+« oder »=« lassen sich überladen. 
Das eröffnet ganz neue Möglichkeiten: Hat 
man sich Klassen für Matrizen, Vektoren, 
komplexe Zahlen oder ähnliches definiert, 
kann man sich durch entsprechende Opera¬ 
tor-Überladungen Datentypen schaffen, die 
den vordefinierten praktisch gleichgestellt 
sind: Schreibt man in C beispielsweise 
MatrixMult(&a,b,c); 
heißt es in C++ lediglich 
a=b*c? 

An Komfort und Lesbarkeit ist das wohl 
kaum zu überbieten. Viele Compiler bieten 
derartige Klassenbibliotheken im Lieferum¬ 
fang, ebenso wie z.B. Klassen für dynamisch 
verwaltete Strings, die beliebig lang werden 
dürfen - einfach mit »+« aneinandergehängt. 
Das nimmt dann auch der berühmt-berüchtig¬ 
ten String-Behandlung von C (die eigentlich 
gar nicht existiert) ihren Schrecken. 

Compiler-Übersicht 

Ein Blick über den Tellerrand genügt, und 
man wird feststellen, daß bisher noch relativ 
wenige C++-Systeme auf dem Markt sind. 
Ein Grund ist der hohe Aufwand, den die 
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Implementierung einer so umfangreichen 
Sprache erfordert. Immerhin hält das den bei 
anderen Programmiersprachen bekannten 
Wirrwarr von Standards (und Abweichungen 
von denselben) in Grenzen. 

Die erste C++-Implementierung überhaupt 
(nicht nur auf dem Amiga) ist der »Frontend« 
von AT&T. Frontend bedeutet, daß dieser 
Compiler die C++-Quelltexte nicht in aus¬ 
führbaren oder assemblierbaren Code um- 
wandelt, sondern einen C-Quelltext erzeugt, 
der dann von einem »anspruchslosen« C- 
Compiler endgültig übersetzt wird. Der Vor¬ 
teil eines solchen Frontends (der selbst in C 
bzw. C++ geschrieben ist) liegt auf der Hand: 
Auf jedem System, für das es einen C-Com- 
piler gibt, kann dieser Frontend unverändert 
benutzt werden. Der Nachteil: Eine solch 
zweistufige Übersetzung kann ganz schön 
lange dauern. 

In Ermangelung eines verbindlichen Stan¬ 
dards - die entsprechende Ansi-Kommission 
tagt zwar schon seit einiger Zeit, ist sich aber 
noch nicht so ganz einig - stellt diese Ur- 
Implementierung den De-facto-Standard dar. 
Seit etwa einem Jahr ist die Version 3.0 des 
Frontends verfügbar, weshalb man auch vom 
3.0-Standard spricht. Davor gab es 2.0 und 
2.1, die sich aber im wesentlichen durch Be¬ 
hebung von Fehlern (Bugs) und nicht in 
bezug auf den eigentlichen Sprachstandard 
unterscheiden. 

Aus dem Unix-Bereich stammt »Gcc«, ein 
kombinierter Compiler für Ansi-C, C++ 3.0 
und »Objective C«, der im Rahmen des 
GNU-Projekts entstand und somit als Public 
Domain, ja sogar als Quelltext verfügbar ist. 
Das System wurde inzwischen auf diverse 


Rechnerfamilien - einschließlich dem Amiga 
- portiert. Leider ist es ein ganz typisches 
Unix-System: Ein in jeder Hinsicht exzellen¬ 
ter und professioneller Compiler, der aber 
enorme Anforderungen an Speicherplatz, 
Festplattenkapazität und vor allem Ge¬ 
schwindigkeit stellt. Außerdem gibt es, wie 
man es von PD-Software kennt, kein richti¬ 
ges Handbuch, also kein gedrucktes und 
schon gar kein deutsches. Mit dem Support 
sieht es naturgemäß ebenfalls nicht rosig aus. 
Auch der Debugger ist leider noch nicht por¬ 
tiert worden. Wer dennoch all das nicht 
scheut und einen entsprechend leistungsfähi¬ 
gen Computer (z.B. einen gut ausgestatteten 
Amiga 3000 oder gar einen Amiga 4000) be¬ 
sitzt, dem kann der Gcc nur wärmstens emp¬ 
fohlen werden. 

Auf MS-DOS-Rechnem dürfte derzeit 
»Borland C++« der beliebteste C++-Überset- 
zer sein. Dieses System implementiert den 
2.0-Standard mit einem zusätzlichen 3.0-Fea- 
ture (den sog. Templates) und wird mit einer 
(zumindest vom Umfang her) imposanten 
Dokumentation zu einem für PC-Verhältnisse 
ausgesprochen fairen Preis geliefert. Daneben 
gibt es für diese Rechnerfamilie noch Portie¬ 
rungen des AT&T-Frontends sowie des Gcc 
und seit jüngstem auch »Microsoft C++«. 

Sie dürfte es aber wohl in erster Linie 
interessieren, wie es auf dem Amiga aussieht. 
Vor einiger Zeit gab es »Lattice C++«, eine 
Portierung des guten alten Frontends (Ver¬ 
sion 1.x) in Verbindung mit der damals aktu¬ 
ellen Version von »Lattice C«. Es wurde aber 
aus schwer nachvollziehbaren Gründen nicht 
weiterentwickelt und ist inzwischen praktisch 
vom Markt verschwunden. 


Neben dem bereits erwähnten als PD 
erhältlichen Gcc sowie »Comeau C++« - 
einem Frontend ohne C-Compiler - ist das 
seit neuestem verfügbare MaxonC++ also die 
einzige Implementierung auf dem Amiga. 
Der Compiler hält sich an den 2.1-Standard 
und ist auch ohne größere Hardware-Anfor¬ 
derungen lauffähig. 1,5 MByte Speicher und 
eine Festplatte ist aber unbedingt empfeh¬ 
lenswert. Bei der Entwicklung wurde insbe¬ 
sondere auf Komfort Wert gelegt. Eine inte¬ 
grierte Entwicklungsumgebung, ein C++- 
Source-Level-Debugger, ein Intuition-Ober¬ 
flächengenerator und ein Macro-Assembler 
sind Bestandteil des Compilers. 

AT&T schuf mit 
»Frontend« den 
De-facto-Standard 

Einer der wichtigsten Schalter ist der 
Umschalter von Ansi-C zu C++. Wie schon 
erwähnt, besteht so die Möglichkeit, Ansi-C- 
Quelltext einfach zu portieren und in kleinen 
Schritten der Objektorientiertheit anzupassen. 

Anhand eines Beispielprogramms soll das 
Zusammenspiel zwischen Editor und Compi¬ 
ler aufgezeigt werden, wenn im Programm¬ 
text Fehler enthalten sind. Sie lassen sich mit 
der Demo-Version des Maxon-C++-Compi- 
lers übersetzen, die Sie auf der Diskette zum 
Heft finden (Seite 114). Starten Sie den Com¬ 
piler nach Abtippen von Listing 1. Er wird 
die in Bild 1 deutlich zu erkennenden Fehler¬ 
meldungen ausgeben. Das Fehlerausgabefen¬ 
ster des Compilers zeigt alle während des 
Compilerlaufs auftretenden Bugs und die ent¬ 
sprechenden Quelltextzeilen an. Um die Feh¬ 
ler im Quelltext zu lokalisieren, muß die ent¬ 
sprechende Fehlerzeile im Compiler-Fenster 
angewählt und mit Anwählen von »Edit« an 
den Editor weitergeleitet werden. Der Cursor 
wird dabei automatisch auf der Fehlerstelle 
positioniert. Nach der Berichtigung der bei¬ 
den Fehler und erneutem Compilieren kann 
das Programm direkt gestartet werden. 

Fazit 

Dem objektorientierten Ansatz wird sicher 
zu Recht nachgesagt, er werde die Software- 
Entwicklung revolutionieren. Bislang deutet 
alles darauf hin, daß C++ sich zu einer der 
wichtigsten Programmiersprachen der 90er 
Jahre entwickeln wird. Es kann jedem Pro¬ 
grammierer nur empfohlen werden, sich mit 
dieser richtungweisenden Konzeption näher 
vertraut zu machen. 

Abschließend möchten wir Ihnen noch ein 
vielsagendes C++-Programm vorstellen - 
eine rudimentäre Implementierung komple¬ 
xer Zahlen. In manchen Programmierspra¬ 
chen (z.B. Fortran) kann man direkt mit kom¬ 
plexen Zahlen rechnen. C++ kennt hingegen 
keine oder ähnliche mathematische Features. 
Das muß kein Nachteil sein, denn sie sind bei 
Bedarf leicht selbst zu implementieren. 
Listing 2 stellt eine solche dar. 
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WaitPort(mywin->UserPort); 
CloseWindow(mywin); 
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jppragma break + 
void main() 
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Func *MyExp = Parse(input); 
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Bild 2: Der Amiga-C++-Compiler und der Source-Level-Debugger in voller 
Aktion - Programmiererherz, was willst du mehr? 
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Es gliedert sich in drei Teile: eine Schnitt¬ 
stellendefinition mit den Deklarationen der 
Klasse »Complex« sowie der übrigen Opera¬ 
tor-Funktionen, ein Implementationsteil und 
ein Beispielprogramm. 

Die wichtigste Deklaration ist die der 
Klasse Complex. Das Schlüsselwort »public« 
gibt an, daß alle nachfolgenden Bezeichner 
von jedem Teil des Programms benutzt wer¬ 
den dürfen. Es gibt hier also keine privaten 
Daten, auf die nur aus der Klasse selbst zuge¬ 
griffen werden darf. In der nachfolgenden 
Zeile werden die Member »r« und »i« für den 
Real- bzw. Imaginärteil der Zahl deklariert. 
Das entspricht Struktur-Membem in C oder 
Record-Feldbezeichnern in Pascal. Interes¬ 
santer ist die folgende Deklaration einer 
Funktion, die wir mit dem gleichen Namen 
wie die Klasse (nämlich »Complex«) be¬ 
zeichnen und zwei Parameter besitzt. Zum 
einen dem Konstruktor, der Objekte des Typs 
Complex automatisch initialisiert. Bei der 
Deklaration eines solchen Objekts läßt sich 
demzufolge wahlweise Real- und Imaginär¬ 
teil angeben, z.B.: 

Coirplex a(l,0), b(-0.5,1.2); 

oder einen oder beide Werte weglassen: 

Conplex c(42), d; 


Das ist deshalb möglich, weil hier für die 
Parameter Default-Argumente (»= 0«) ange¬ 
geben sind. Der Compiler setzt solche Argu¬ 
mente automatisch ein, wenn bei einem Kon¬ 
struktor- oder Funktionsaufruf Argumente 
fehlen. 

Den Abschluß der Klassendefinition bildet 
der Prototyp der Member-Funktion (oder 
auch Methode) »conj«. Diese Funktion läßt 
sich auf Objekten des Typs Complex aufru- 
fen und liefert die konjugiert-Komplexe. Das 
angehängte »const« teilt dem Compiler mit, 
daß »conj« das Objekt, auf dem es aufgeru- 
fen wird, nicht verändert. 

Nach der Klassendefinition folgen die zu 
überladenden Operatoren. Dies sind »+«, »-«, 
»*« und »/« für die vier Grundrechenarten 
sowie die Vergleichsoperationen »==« und 
»!=«. Da es auf komplexen Zahlen bekannt¬ 
lich keine vollständige Ordnung gibt, können 
wir uns »kleiner«, »größer« usw. ersparen. 
Das »&« vor den Parametern gibt an, daß die 
Argumente als Referenz zu übergeben sind. 

Es folgt noch eine interessante Operator- 
Definition, die ausführlicherer Erläuterung 
bedarf: Die Ausgabe von Daten erfolgt in 
C++ über die Klasse »ostream«, auf die der 
Operator »«« überladen ist. Das Objekt 


»cout« der Klasse »ostream« steht z.B. für 
die Standard-Ausgabe. Mit Anweisungen wie 
cout « "Das Ergebnis ist " « x « 
lassen sich Daten aller Art ausgeben. Der 
Programmierer selbst kann »«« weiter über¬ 
laden und so Ausgabefunktionen für eigene 
Datentypen definieren - in diesem Fall als 
Routine für die Klasse »Complex«. 

Die eigentliche Implementation der so 
definierten Funktionen und Operatoren birgt 
für C-Programmierer nicht viel neues, einmal 
abgesehen davon, daß bei »conj« der Klas¬ 
senname angegeben werden muß (verschie¬ 
dene Klassen können nämlich gleichnamige 
Funktionen besitzen) und daß ein Operator 
wie eine ganz normale Funktion aussieht, nur 
daß ihr Name eben z.B. »operator +« ist. 

Das Listing demonstriert die Klasse »Com¬ 
plex«. Variablen (Objekte) der Klasse »Com¬ 
plex« werden wie vordefinierte numerische 
Variablen deklariert und lassen sich direkt 
mit den Operatoren verknüpfen. rz 
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1 

// Einfache Implementierung komplexer Zahlen in C++ 

57 

Conplex operator / (const Complex &cl, const Complex &c2) { 

2 

// Geschrieben von Jens Gelhar 20.11.92 

58 

•Complex nenner = cl * c2.conj(); 

3 

#include <iostream.h> // Includedatei für Ein- und Ausgabe 

59 

double zaehler = c2.r*c2.r + c2.i*c2.i; 

4 


60 

retum Complex(nenner.r/zaehler, nenner.i/zaehler); 

5 

// ***** Die Klassendefinition und Funktionsprototypen ***** 

61 

} 

6 

dass Complex { 

62 


7 

public: // d. h. keine privaten Bezeichner 

63 

int operator == (const Conplex &cl, const Conplex &c2) { 

8 


64 

retum (cl.r == c2.r && cl.i == c2.i); 

9 

double r, i; // Real- und Imaginärteil 

65 

} 

10 


66 


11 

Complex(double re=0, double im=0); // Konstruktor 

67 

int operator != (const Complex tcl, const Complex &c2) { 

12 


68 

retum (cl.r != c2.r II cl.i != c2.i); 

13 

Complex conjO const; // berechnet konjugiert-komplexe 

69 

} 

14 

}; 

70 


15 


71 

ostream &operator << (ostream fitos, const Complex &c) { 

16 

// Die vier Grundrechenarten: 

72 

if(c.r != 0) 

17 

Complex operator + (const Complex &cl, const Complex &c2); 

73 

{ if (c.i > 0) 

18 

Complex operator - (const Complex &cl, const Complex &c2); 

74 

os « "(■ « c.r « * +• « c.i « *i)"; 

19 

Complex operator * (const Complex &cl, const Conplex &c2); 

75 

eise if (c.i < 0) 

20 

Complex operator / (const Complex &cl, const Complex &c2); 

76 

os « "(■ « c.r « " -■ « -c.i « *i)"; 

21 


77 

eise 

22 

// Vergleichs-Operationen: 

78 

os « c.r; 

23 

int operator == (const Complex &cl, const Complex &c2); 

79 

} 

24 

int operator != (const Complex &cl, const Complex &c2); 

80 

eise 

25 


81 

if (c.i != 0) 

26 

// Ausgabe-Funktion: 

82 

os « c.i « "i"; 

27 

ostream koperator « (ostream äos, const Complex &c); 

83 

eise 

28 


84 

os « ■0"; 

29 

// ***** Implementation ***** 

85 

return os; 

30 

Complex::Conplex(double re, double im) { 

86 

} 

31 

r = re; 

87 


32 

i = im; 

88 

// ***** Ein simples Beispielprogramm: ***** 

33 

} 

89 

void main() { 

34 


90 

Conplex x, y; 

35 

Complex Complex::conj() const { 

91 


36 

Complex ergebnis(r, -i); 

92 

cout « 'Bitte geben Sie zwei komplexe Zahlen ein:" « endl; 

37 

retum ergebnis; 

93 

cout « "x (Realteil): "; 

38 

} 

94 

ein » x.r; 

39 


95 

cout « "x (Imaginärteil): "; 

40 

Coirplex operator + (const Conplex &cl, const Complex &c2) { 

96 

ein » x.i; 

41 

Complex ergebnis(cl.r+c2.r, cl.i+c2.i); 

97 


42 

retum ergebnis; 

98 

cout « "y (Realteil): 

43 

} 

99 

ein » y.r; 

44 


100 

cout « "y (Imaginärteil): •; 

45 

Complex operator - (const Complex &cl, const Complex &c2) { 

101 

ein » y.i; 

46 

Complex ergebnis(cl.r-c2.r, cl.i-c2.i); 

102 


47 

retum ergebnis; 

103 

cout « endl; 

48 

} 

104 

cout « *x + y = " « x+y « endl; 

49 


105 

cout « "x - y = " « x-y « endl; 

50 

Complex operator * (const Complex &cl, const Complex &c2) { 

106 

cout « *x * y = ’ « x*y « endl; 

51 

Conplex ergebnis; 

107 

cout « "x / y = " « x/y « endl; 

52 

ergebnis.r = cl.r*c2.r - cl.i*c2.i; 

108 

} © 1993 M&T 

53 

ergebnis. i = d.r*c2.i + cl.i*c2.r; 



54 

55 

retum ergebnis; 

} 

Listing 2: Die Implementation Komplexer Zahlen ist in 

56 


C++ schnell erledigt 
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PROGRAMMIERSPRACHEN 


Modula-2-Ableger 


Nur der Amiga hat sie - 

Cluster 


Cluster ist eine für den Amiga 
nicht mehr ganz neue Program¬ 
miersprache. Sie lehnt sich ans 
Modula-2-Konzept an, verfügt 
allerdings über einige außerge¬ 
wöhnliche Besonderheiten, 
von Thomas Pfrengle 

A uf dem Amiga gibt's jede Menge Pro¬ 
grammiersprachen. Am beliebtesten 
ist »C« - nicht zuletzt aufgrund des 
Amiga-Betriebssystem-Konzepts. Mittler¬ 
weile mausern sich Oberon-2 und Modula-2 
zu ernsten Rivalen des scheinbar allmächti¬ 
gen C. Auch Cluster mischt seit zwei Jahren 
mit. 

Cluster basiert auf Modula-2 und ist nach 
wie vor in der Lage (Version 2.0, siehe 
Kasten), Quelltexte dieser Sprache zu über¬ 
setzen. Das Sprachkonzept von Modula-2 
hingegen schöpft nicht alle Cluster-Fähigkei¬ 
ten aus und ist nur dann angebracht, wenn 
Portabilität unumgänglich ist. Wie sieht nun 
ein Cluster-Programm aus? Bild 1 demon¬ 
striert den grundsätzlichen Aufbau. Die Ele¬ 
mente IMPORT, TYPE, VAR, CONST, 
EXCEPTION und PROCEDURE dürfen in 
beliebiger Reihenfolge auftreten, sind aber 
nicht zwingend. Ebenso ist der CLOSE-Teil 
optional. In Implementationsmodulen ist der 
BEGIN-Teil ebenfalls unnötig. 

Der Importteil 

Auffällig ist der IMPORT-Teil, da er doch 
einige Unterschiede zu Modula-2 aufweist. 
Für all die Leser, die mit Modula nicht ver¬ 
traut sind, einige Anmerkungen zum Modul- 
Konzept: Ein Programm besteht im allgemei¬ 
nen nicht nur aus einem Modul. Dies hat zum 
einen den Vorteil, daß Programme über¬ 
schaubar bleiben, zum anderen bietet das die 
Möglichkeit, Prozeduren und Typen eines 
speziellen Gebiets zusammenzufassen. So 
lassen sie sich einfach importieren, ohne eine 
Routine immer wieder neu zu schreiben. Da 
die einzelnen Module nur einmal übersetzt 
und anschließend hinzugelinkt werden, spart 
man bei der Übersetzung des Hauptmoduls 
zusätzlich Zeit. 

Derartige Bibliotheksmodule haben einen 
geringfügig modifizierten Aufbau als der nor¬ 
maler Module: Sie setzen sich aus einem 


Definitions- und Implementations-Teil 
zusammen. Die Trennung hat gegenüber dem 
Konzept von Oberon (nur ein Modul, das 
sowohl Implementation als auch Definition 
enthält) folgende Vorteile: Einmal entspricht 
sie mehr dem Prinzip des Information- 
Hidings (Verbergen von Informationen), da 
bei Großprojekten mit vielen Programmie¬ 
rern nur die Definitionsmodule untereinander 
auszutauschen sind, ohne daß die Implemen¬ 
tationsteile explizit bekannt sein müssen 
(Know-how-Schutz). Zum anderen verhin¬ 
dert man so, daß unbeabsichtigt Implementa- 
tionsmodule verändert werden, was zu Inkon¬ 
sistenzen im Gesamtprojekt führte (wenn 
jeder Programmierer unterschiedliche Imple¬ 
mentationsteile besäße). Außerdem lassen 
sich so z.B. hardwarenahe Prozeduren kap¬ 
seln und der Benutzer wird mit irgendwel¬ 
chen Registern gar nicht erst konfrontiert - 
für sie ist es ein ganz normales Hochspra¬ 
chenmodul. 

Ein weiterer Vorteil der Trennung ist, daß 
bei einer Änderung in der Implementation 
nicht alle davon abhängigen Module neue zu 
kompilieren sind. Das gilt aber nur, solange 
die Definitionsdatei unverändert bleibt. Ein 
zusätzlicher Nebeneffekt ist die gute Über¬ 
sichtlichkeit und Dokumentation der Schnitt¬ 
stelle. Man erkennt recht schnell, was sich 


von einem Mo¬ 
dul importieren 
läßt. In Oberon- 
2 z.B. kenn¬ 
zeichnet man zu 
exportierende 
Objekte mit dem 
Sternoperator 
»*«. Durch das 
Trennen in Defi¬ 
nitions- und Im¬ 
plementations¬ 
modul wird es 
möglich, daß 
sich zwei Mo¬ 
dule gegenseitig importieren können. Bei 
Cluster besteht darüber hinaus die Möglich¬ 
keit, Definitionsmodule gegenseitig zu 
importieren. Das ist z.B. fürs DOS notwen¬ 
dig, da in »Dos.Prozess« ein Window-Pointer 
aus dem Intuition-Modul benötigt wird, Intui¬ 
tion aber auch das Dos-Modul importiert. 

Zurück zum IMPORT-Teil. Dort läßt sich 
all das importieren, was im Definitionsteil 
eines anderen Moduls definiert wurde. Das 
kann auf verschiedene Arten geschehen: 

□ Direkter Import: Es wird der Name des zu 
importierenden Objekts angegeben, z.B. 
»Read«. Daraufhin ist das Objekt direkt über 
seinen Namen ansprechbar, ohne es jedesmal 
mit dem Modulnamen zu qualifizieren. 

□ Qualifizierter Import: Man verwendet die 
einzelnen Objekte, indem man sie über den 
Modulnamen qualifiziert, z.B. »InOut.Read- 
String«. Dies ist dann notwendig, falls in 
zwei Modulen gleiche Bezeichner Vorkom¬ 
men und man sie in einem Modul verwendet. 
Um Tipparbeit zu sparen, bietet das Schlüs¬ 
selwort »AS« die Möglichkeit, sie umzube¬ 
nennen. AS ist optional, kann auch fehlen. 

□ Import über Importgruppen: Mit dem 
Schlüsselwort »GROUP« lassen sich in Defi¬ 
nitionsmodulen Bezeichner oder andere 
Importgruppen zu einer Einheit zusammen¬ 
fassen, z.B. »WriteGrp«. Somit entfällt die 


Rund um Cluster 


Cluster ist eine integrierte Entwicklungsumge¬ 
bung: Aus dem Editor heraus läßt sich direkt in 
den Speicher kompilieren, linken, »maken« und 
das Programm starten. Beim Kompilieren hält 
Cluster die Symboldateien automatisch in einem 
dynamischen Cache - so verhindert man ständi¬ 
ges Nach- bzw. Neuladen schon verwendeter 
Symboldateien. Der Loader. verantwortlich fürs 
Ausführen von zuvor übersetzten Programmen, 
besitzt die Fähigkeit, auftretende Laufzeitfehler 
abzufangen und mit Zeilen- und Modulangabe im 
Quelltext zu melden. 

Der Editor verfügt neben vielen anderen Funk¬ 
tionen wie automatischem Fettdruck verwendeter 
Schlüsselwörter über die Möglichkeit, alle Tasten 
mit Makros zu belegen. Die eigenwillige Ober¬ 
fläche des Editors war in der Vergangenheit ein 
Kritikpunkt. Mit der neuen Cluster-Version V2.0 
wird ein Amiga-konformer Editor sowie Cli/- 


Shell-Versionen von Compiler. Linker. Loader 
und Make mit AREXX-Ports ausgeliefert, ebenso 
eine Vorversion vom Debugger. 

Beim Compiler handelt es sich um einen 
Single-Pass-Compiler (6000 Zeilen pro Minute 
Übersetzungsgeschwindigkeit und über 1600 
Dhrystones/s auf einem MC68000-Amiga; bei 
einem Amiga mit 33 MHz MC68030-Prozessor 
erreicht er sogar 13 000 Dhrystones/s). Er gene¬ 
riert lauff^higen Code für alle 68xxx-Prozessoren 
einschließlich dem MC68040 und dem 68882- 
Koprozessor. Reentrante Programme im kleinen 
Datenmodell lassen sich genauso kreieren wie 
Libraries und Devices. Der selektiv operierende 
Linker bindet nur die wirklich benötigten Objekte 
und erstellt so sehr kompakte Programme. 

Bezugsadresse: DTM GmbH, Dreiherrenstein 6a, W-6200 Wies- 
baden-Auringen, Tel.: (0 61 27) 40 65, Fax (0 61 27 ) 6 62 76 
Preis: ca. 400 Mark 
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lange Importliste am Modulanfang. Im übri¬ 
gen ist nicht nur zu Beginn eines Moduls das 
Importieren erlaubt: auch innerhalb einer 
Prozedur geht das. 

Die Typdeklaration 

Die in Cluster verwendeten Standardtypen 
finden Sie in Bild 2. Der Typ »STRING« ist 
hier ein echter Stringtyp und nicht wie in C 
oder Modula als »ARRAY OF CHAR« mit 
abschließendem Null-Byte definiert. Statt 
dessen ist er als RECORD mit der Länge 
(Integer) an erster Position und einem Null- 
Byte-terminiertem »ARRAY OF CHAR« 
implementiert. Hierbei ist das letzte Null- 
Byte nicht in der Länge enthalten: 

STRING = RECORD 

len : INTEGER; 
data : ARRAY [0..MAX] OF CHAR 
END 

Diese Definition bietet enorme Vorteile: 
Abhängig von der gestellten Aufgabe ist die 
Behandlung eines Strings unterschiedlich 
effizient: Möchte man z.B. den String kopie¬ 
ren, richtet man sich nach dem Null-Byte. 
Fürs Parsen bietet sich hingegen das Längen¬ 
element an. Cluster erlaubt sogar die Zuwei¬ 
sung von Strings mit unterschiedlicher Maxi¬ 
mallänge. Hier prüft der Compiler, ob sie 
zulässig ist. 

Neben vorgegebenen Standardtypen lassen 
sich eigene anlegen: 

O Unterbereichstypen z.B. [3..211] 

O Aufzählungstypen, z.B. (Rot,Gruen,Blau). 

Cluster erlaubt die Angabe von Elementen 
innerhalb eines Aufzählungstypen mit glei¬ 
chem Namen. Der Compiler versucht dann, 
aus dem Kontext den richtigen Typ zu ermit¬ 
teln. Ist das nicht möglich, muß man das Ele¬ 
ment über den Typnamen qualifizieren. 
Außerdem lassen sich Aufzählungstypen mit 
einem vorgegebenen Wert starten oder nach 


MODULE BeispielModul 

FROM InOut AS io IMPORT Read,WriteGrp; 

IMPORT FileSystem AS fs; 

TYPE 

Mögliche Typdeklarationen 
VAR 

Mögliche Variablendeklarationen. 

CONST 

Mögliche Konstantendeklarationen 
EXCEPTION 

Mögliche Exceptiondeklarationen 
PROCEDURE 

Procezedurdeklarationen 

GROUP 

Deklaration von Importgruppen (Nur in 
Defintionsmodulen) 

BEGIN 

Hauptprogramm 

CLOSE 

Closeteil 

END Beispielprogramm. © 1993 M&T 

Bild 1: So präsentiert sich das Grund¬ 
gerüst eines Cluster-Programms - die 
Ähnlichkeit zur Programmiersprache 
Modula-2 ist unverkennbar 


einer Lücke mit einem anderen Wert fortset¬ 
zen. Somit vermeidet man lästige Füllein¬ 
träge in den Systemmodulen. 

O Flags = (Flagl,Flag2,Flag3,Flag255= 
255,Flag256); 

O Mengen: Aus Aufzählungs- oder Unterbe¬ 
reichstypen mit maximal 32 Elementen las¬ 
sen sich Sets oder auch Mengen bilden. Im 
Gegensatz zu C und Oberon überprüft Clu¬ 
ster, ob die Flags zum Set-Typen passen. Es 
ist demnach unmöglich, ein Window-Flag 
und ein Gadget-Flag als Screen-Flags zu 
mißbrauchen. Bei der Wertzuweisung ist es 
nicht mehr notwendig, den Typnamen anzu¬ 
geben: 

FlagSet = SET OF [Flagl..Flag3]; 

SetVar := {Flag,Flag3} 

O Records: Records sind Zusammenfassun¬ 
gen mehrerer Variablen. Sie sind für Daten, 
die man z.B. in einem Rutsch einer Prozedur 
übergeben oder speichern möchte, ideal. Auf 
die einzelnen Record-Elemente greift man 
zu, indem man sie über den Record-Element¬ 
namen anspricht. Record-Elemente dürfen 
jeden Typ besitzen, sogar Records selbst. 
Von Records lassen sich Nachfolger definie¬ 
ren, die zuweisungskompatibel zu ihrem Vor¬ 
gänger sind. Ein Beispiel zeigt Bild 3. 

Das erste Element des Records »Message« 
ist kein Node, da es als Nachfolger von Node 
definiert ist. Dieses läßt sich demzufolge an 
alle Prozeduren übergeben, die eine Node- 
Struktur erwarten, ohne eine Pointer-Konver¬ 
tierung durchführen zu müssen. 

O Arrays: Man kann sie sich als eine Ele¬ 
mentliste eines Typs vorstellen, die über 
einen Index anzusprechen sind. Sie eignen 
sich hervorragend im Zusammenhang mit 
Schleifen, möchte man auf viele Elemente 
die gleiche Operation anwenden. 

Selbstverständlich sind auch mehrdimen¬ 
sionale Arrays möglich. Außerdem läßt sich 
nicht nur mit festen, sondern auch mit offe¬ 
nen Arrays arbeiten. Von diesem Typ kann 
man sich zwar keine Variablen anlegen, sie 
bieten jedoch die Option, vom offenen einen 
festen Typ abzuleiten, der dann zum offenen 
zuweisungskompatibel ist (daher eignen sich 
offene Arrays sehr gut als Übergabeparame¬ 
ter an Prozeduren). Zudem ist es möglich, 
einen Pointer-Typen zu definieren und an¬ 
schließend ein Feld bestimmter Länge zu 
reservieren. Der Compiler nimmt auch hier 
eine Bereichsüberprüfung vor. 

O Prozedurtypen: Einer Variablen dieses 
Typs lassen sich alle Prozeduren zuweisen, 
die dem Aufbau des Prozedurtyps entspricht: 

TYPE ProcType = PROCEDURE(i : INTEGER; 

narae : STRING); 

Diesem kann man sich all die Prozeduren 
zuweisen, deren erster Parameter ein INTE¬ 
GER- und zweiter ein STRING-Wert ist. Wo 
ist der praktische Nutzen eines solchen Typs? 
Stellen Sie sich vor: Sie rufen an mehreren 
Stellen eine Prozedur auf. Unter bestimmten 
Umständen benötigt man an dieser Stelle 
aber eine andere Prozedur gleichen Typs. Der 
aufwendige Weg sieht so aus, an jeder Stelle 
eine IF-Abfrage zu implementieren und ent¬ 


sprechend die Funktion aufzurufen. Einfacher 
ist es, anstelle von Prozeduren eine Prozedur- 
variable einzuführen und diese vor dem Auf¬ 
ruf adäquat zu belegen. 


SHORTCARD, CARDINAL, LONGCARD 
SHORTINT, INTEGER, LONGINT 
FFP, REAL, LONGREAL 
BOOLEAN, LONGBOOL (Long hier zur C- 
Kompatibilität in Systemmodulen) 

CHAR, LONGCHAR 

ANYTYPE: Kann jeder Typ sein; nur als Über¬ 
gabeparameter zu gebrauchen; man kann nur auf 
seine Länge und seine Adresse zugreifen (ver¬ 
gleichbar zu ARRAY OF BYTE' in Modula-2). 
ANYPTR: Vergleichbar ADDRESS in Modula- 
2 sowie STRING. 


Bild 2: Die von Cluster zugelassenen 
Variablentypen - einige wurden in 
Anlehnung ans Amiga-Betriebssystem 
implementiert 

In Cluster besteht hier nun die Möglichkeit 
(die sonst nur noch in Modula-3 vorhanden 
ist), an einen Übergabeparameter einer Pro¬ 
zedur nicht nur globale Prozeduren zu über¬ 
geben, sondern auch lokale. Oft ist das vor¬ 
teilhaft, da lokale Prozeduren auch auf lokale 
Variablen der sie umgebenden Prozeduren 
zugreifen können. 

O Konstanten : Konstanten werden in Cluster 
wie in Modula-2 deklariert, d.h. 

CONST 

Name = Wert, 

Dabei lassen sich nicht nur einfache Konstan¬ 
ten deklarieren, auch Konstanten beliebigen 
Typs, also Records, Arrays oder Pointer, sind 
davon nicht ausgenommen. 

Selbst das Vordefinieren von Konstanten 
ist gültig. Gibt man z.B. im Definitionsmodul 
eine Konstante an, der letztlich aber erst im 
Hauptprogramm ein Wert zugewiesen wird, 
vermeidet man, daß bei einer Wertverände¬ 
rung alle Module erneut zu kompilieren sind. 
Diese Fähigkeit ermöglicht es auch, kon¬ 
stante verkettete Listen aufzubauen. So 
deklariert man z.B. viele Systemstrukturen 
als Konstanten und muß die jeweiligen Werte 
nicht während der Laufzeit zuweisen. 

V ariablendeklarationen 

Zum Teil kennen wir sie schon aus vorigen 
Beispielen. Da es sich bei Cluster um einen 
Single-Pass-Compiler handelt, ist es notwen¬ 
dig, Variablen vor der ersten Verwendung 
anzugeben - ansonsten meckert er. Das 
geschieht durch Angabe des Schlüsselworts 
»VAR« gefolgt von den Namen. Den Namen 
schließt sich der Doppelpunkt und eine Typ¬ 
definition an. Bis hier entspricht das genau 
der Syntax von Modula-2. In Cluster aber 
dürfen Sie die Variablen zusätzlich mit einem 
Initialwert versehen: 

VAR i : INTEGER :=10 

Feld :=TestArray:(1,2,3,4,5,3,6,6,-3,0); 

Möchte man, daß eine Variable ständig in 
einem Register liegt, kann man es bei der 
Deklaration angeben: 
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VAR i IN D2 : INTEGER; 

Durch das Schlüsselwort »STATIC« 
erreicht man, daß lokale Variablen nach Ver¬ 
lassen der Prozedur ihren Wert nicht verlie¬ 
ren, sondern beim erneuten Aufruf immer 
noch denselben Wert innehaben. Im Prinzip 
ließe sich hierfür auch eine globale Variable 
verwenden. Der Vorteil von STATIC ist 
jedoch der, daß die Variable nur innerhalb 
der Prozedur bekannt ist. 

O Attribute: Darunter versteht Cluster spezi¬ 
elle Eigenschaften von Typen und damit auch 
von Variablen, die durch »Variablen/Typna- 
men'Attributname« abzufragen sind (Bild 4). 
O Der BEGIN-Teil: Hier findet der eigentli¬ 
che Programmablauf statt. Er besteht aus 
Anweisungen, getrennt durch Semikola. Die 
von Cluster angebotenen Kontrollstrukturen 
sind vielfältig. Um Variablen mit mehreren 
Werten zu vergleichen, verwendet man in 
Modula-2 die »CASE«-Anweisung. In Clu¬ 
ster mutierte sie zwecks größerer Geschlos¬ 
senheit (s. »WHILE«) zu einem »IF KEY«. 

In Cluster darf innerhalb des CASE- bzw. 
IF KEY-Konstrukts der Vergleich nicht nur, 
wie in Modula-2 üblich, mit Konstanten 
erfolgen, auch Variablen sind erlaubt. Die 
Anweisungsfolge wird allerdings nur dann 
ausgeführt, wenn ebenfalls die AND_IF- 
Anweisung wahr ist. So entstand ein Neben¬ 
effekt: Der »OF«-Operator ist für allgemeine 
Boolesche Bedingungen frei (z.B. in 
WHILE- oder REPEAT-Schleifen): 

IF c OF "a","b","c".."e",varl THEN END 


MinNodePtr 

= POINTER TO MinNode; 

MinNode 

= RECORD 

succ, 

pred ; SAMEPTR; 

END; 

NodePtr 

= POINTER TO Node; 

Node 

= RECORD OF MinNode 

type ; NodeType; 
pri : NodePri; 
name : SysStringPtr? 

END? 

MessagePtr 

= POINTER TO Message; 

Message 

= RECORD OF Node 

replyPort : MsgPortPtr; 
msgSize : CARDINAL; 

END; 


Bild 3: Records spielen eine zentrale 
Rolle im Sprachkonzept von Cluster 
und werden insofern extrem flexibel 
gehandhabt 

Dabei wird c mit jedem der nachfolgenden 
Werte verglichen. Während des Vergleichs 
verharrt c jedoch in einem Register, was 
einen Geschwindigkeitsgewinn zur Folge hat. 

Schleifen 

O Die REPEAT-Schleife: 

REPEAT 

Anweisungsfolge 
UNTIL (Boolesche Bedingung); 

O Die WHILE-Schleife: 

WHILE (Boolesche Bedinung) DO 


Anweisungsfolge 
END; 

Die Schleife wird nur dann ausgeführt, 
wenn die Boolesche Bedingung wahr ist. Im 
Unterschied zur REPEAT-Schleife ist die 
Anweisungsfolge nicht unbedingt abzuarbei¬ 
ten. WHILE wurde um »OR_WHILE« und 
»ELSE« erweitert. Durch diese Maßnahme 
ist die LOOP-Schleife praktisch überflüssig. 

O WITH: Diese Anweisung erlaubt im allge¬ 
meinen den vereinfachten Zugriff auf 
RECORD-Elemente. Eine Einschränkung 
war bislang allerdings hinzunehmen: Der 
Zugriff ist nur auf einen Record desselben 
Typs gleichzeitig möglich. Bei Cluster gibt's 
diese Einschränkung nicht. WITH wurde 
insofern modifiziert, daß es sich auf jeden 
TYP anwenden läßt. Eine Variable einfachen 
Typs befördert Cluster über den gesamten 
WITH-Bereich in ein Register, was zu einem 
Geschwindigkeitsgewinn führt. 

Prozeduren und Funktionen 

Innerhalb von Prozeduren und Funktionen 
dürfen die gleichen Konstrukte auftauchen, 
die wir schon vom Modul kennen. 

Cluster-Prozeduren und -Funktionen haben 
jedoch einige Besonderheiten: Als Übergabe¬ 
parameter gibt es VAR-, REF-, und Wertepa¬ 
rameter. Der Unterschied: Bei einem Werte¬ 
parameter wird der Wert kopiert - Verände¬ 
rungen in der Prozedur beziehen sich also 
nicht auf die übergebene Variable. Bei VAR- 
Parametem wird nur ein Zeiger auf die Varia¬ 
ble übergeben, Änderungen in der Prozedur 
verändern auch die übergebene Variable 
außerhalb der Prozedur. In vielen Fällen 
möchte man das ausschließen. Handelt es 
sich aber z.B. um ein Array, ist kopieren zu 
zeitaufwendig. Hier verwendet man den 
REF-Parameter. Auch hier übergibt man nur 
die Adresse, Schreibzugriffe innerhalb der 
Prozedur sind nicht möglich. 

Übergabeparameter lassen sich als Regi¬ 
sterparameter definieren: 

PROCEDURE Reg(i IN Dl : INTEGER); 

Es ist möglich, in Cluster Funktionen mit 
komplexem Typ als Rückgabewert anzuge¬ 
ben (z.B. Records oder Arrays). Sogar offene 
Typen wie z.B. Strings sind erlaubt. Einer 
solchen Funktion lassen sich sogar direkt 
Parameter an REF-Parameter übergeben: 

Str3:=Concat(*foo ",Seg(strl,4,5), 

Seg(str2,6,7),■ bar"); 

Prozedurparameter kann man vordefinie¬ 
ren. Beim eigentlichen Aufruf müssen sie 
nicht angegeben werden. Falls doch, ge¬ 
schieht das gezielt über den Namen: 

PROCEDURE Test(x,y : INTEGER := 0; 

flag : B00LEAN :=TRUE); 

Test;Test(1); 

Test(1,2); 

Test(flag:=FALSE);... 

Außerdem lassen sich Prozeduren mit 
beliebig vielen Parametern deklarieren: 

PROCEDURE 

WriteStrings(REF strs ; LIST OF STRING); 

Intern wird ein Parameter vom Typ LIST 
OF als ein offenes Array repräsentiert: 


PROCEDURE 

WriteStrings(REF strs : LIST OF STRING); 
VAR i : INTEGER; 

BEGIN 

FOR i;=0 TO strs'MAX DO 
WriteString(strs[i]); 

END 

END WriteStrings; 

So ist die Prozedur aufzurufen: 

WriteStrings("Dies ist ein Test"); 

oder 

WriteStrings ("Test Nummer \IntToString(i)); 


Attribut 

Bedeutung 

’SIZE 

Göße in Bytes 

’PTR 

Liefert Pointer auf die Variable 

•ADR 

Liefert Adressnummer als 

LONGINT 

RANGE 

Liefert bei offenen Arrays und 
Strings die Maximallänge 

’MIN 

Liefert Minimalwert eines Typs. 

•MAX 

Liefert Maximalwert oder Num¬ 
mer des höchsten Eintrags eines 
Arrays oder Strings 


Bild 4: Eine der Eigenschaften von 
Cluster sind die Attribute für Typen 
und Variablen 


Cluster bietet auch einige maschinennahe 
Elemente. Sie sollte man aber immer in 
»Low-Level«-Module kapseln. Zum einen 
existiert ein Inline-Assembler, über den man 
auf außerhalb gelegene Variablen zugreifen 
kann (MOVE rec.i,D0), der darüber hinaus 
auf Wunsch einen Typcheck durchführt. 
Auch die Condition-Codes des Prozessors 
lassen sich direkt abfragen: 

REPEAT 

DEC(i) 

UNTIL = ; 

Die Schleife terminiert erst dann, wenn das 
Zero-Flag gesetzt ist. Dieser oder ähnlicher 
Code sollte nur in Low-Level-Modulen Ver¬ 
wendung finden. 

Falls eine Pointer-Variable in einem Regi¬ 
ster liegt, ist es möglich, ohne Umwege den 
Postincrement- bzw. Predecrement-Modus 
des MC68000-Prozessors auszunutzen: 

pl+ A :=p2+ A . 

Diese Anweisung schreibt den Wert, auf 
den p2 zeigt, in die Adresse von pl. Beide 
Pointer werden anschließend um die Länge 
ihres Typs erhöht. 

Ausnahmebehandlung durch 
»TRY...EXCEPT« und »RAISE/ASSERT« 

Cluster ist die bisher einzige Sprache auf 
dem Amiga, die dieses mächtige Konzept 
bietet. Es ermöglicht erstmals auf die Rück¬ 
gabewerte zu verzichten, die lediglich anzei- 
gen, ob eine Prozedur erfolgreich war oder 
nicht. Somit entfallen eine Menge lästiger 
Vergleiche. Erreicht wird das durch selbstde- 
finierte Exceptions (Ausnahmebehandlun¬ 
gen), die Prozeduren im Fehlerfall setzen. 
Die Exception ist außerhalb abzufangen und 
dementsprechend zu reagieren. Dies ge¬ 
schieht zum einen durch »RAISE« und 
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»ASSERT«, zum anderen durch 
»TRY..EXCEPT«. Beim Einlesen einer Datei 
ist es z.B. nicht notwendig, nach jedem Lese¬ 
vorgang einen Vergleich auf Erfolg durchzu¬ 
führen, da beim Dateiende die Exception 
»EOF« ausgelöst wird und das Programm 
sofort in den »EXCEPT«-Teil verzweigt. Mit 
Hilfe der TRY..EXCEPT-Anweisung lassen 
sich auch alle System-Laufzeitfehler behan¬ 
deln, z.B. die unbeliebte Division durch Null. 
Eine Exception wird so definiert: 

EXCEPTION 

DivO = "Division durch 0"; 

Den angegebenen String erhält man als 
Laufzeitmeldung, sofern das Abfangen der 
Exception nicht möglich war. 

Ausgelöst wird sie auf zwei Arten: 

□ RAISE(Exceptionname) 

□ ASSERT((Boolesche Bedingung), Excep- 
tionname) 

ASSERT löst die Exception nur dann aus, 
wenn die Boolesche Bedingung unwahr ist. 

ASSERT(memSize>1000,LowMemory); 

Ressource-Verwaltung 

Cluster benötigt keinen sog. Garbage- 
Collector, über den sich Ressourcen komfor¬ 
tabel und sicher verwalten lassen. Cluster 
bietet ein System, mit dem sich alle Ressour¬ 
cen (Speicher, Dateien usw.) zu sog. Kontex¬ 
ten zusammenfassen lassen, die nach 
Gebrauch in einem Rutsch freigegeben wer¬ 
den. Es ist möglich, bei jeglicher Anforde¬ 
rung einen eigenen Kontext anzugeben. Tut 
man das nicht, hängt Cluster diesen dem 
Aktuellen an und gibt ihn am Programmende 
automatisch frei. Weiß man, über welche 
Ressourcen man verfügt und gibt diese dem 
System zurück, bietet sich das 
»TRACK..CLOSE..END«-Konstrukt an: 


TRACK 

Allozierungen 

CLOSE 

Anweisungen 

END 

Sie erzeugt einen neuen Kontext, erklärt 
ihn zum aktuellen und gibt ihn wieder frei. 
Anschließend ist der vorherige Kontext wie¬ 
der der aktuelle. Der Clou: Der Kontext wird 
auch dann zurückgesetzt, wenn eine Excep¬ 
tion oder ein Laufzeitfehler auftritt. Der 
CLOSE-Teil wird immer durchlaufen, unab¬ 
hängig davon, ob eine Exception vorkam 
oder nicht. 

Eine beliebte Variante ist ein 
»TRACK..END«-Konstrukt. umgeben von 
»TRY..EXPECT«. Tritt eine Exception auf, 
muß man sich ums Freigeben nicht kümmern. 
Alternativ lassen sich Kontexte auch struktur¬ 
bezogen verwenden. Wenn man z.B. alle Ele¬ 
mente einer Struktur kontextrelativ angibt, 
lassen sich diese durch einfaches Freigeben 
des Kontexts ebenfalls dem System zur Ver¬ 
fügung stellen. Das Ganze funktioniert im 
Unterschied zu einem Garbage-Collector 
ohne Performance-Einbußen. Ein weiterer 
Vorteil ist, daß sich so nicht nur Speicher, 
sondern auch andere System-Ressourcen 
durchs Laufzeitsystem verwalten lassen. 

Generische Module 

Hierbei handelt es sich um Fähigkeiten, 
Module unabhängig von Typen zu beschrei¬ 
ben. Beispiel: Ein typsicheres Modul zur 
Verwaltung verketteter Listen ließ sich bis¬ 
lang nur für einen Typ implementieren. Die 
Verwendung mit einem anderen ähnlichen 
Typ stieß auf Ablehnung beim Compiler. Es 
blieb nicht anderes übrig, als den Quelltext 
zu modifizieren und neu zu kompilieren. Es 


ergab sich, daß ein Modul in mehreren Vari¬ 
anten existierte. Generische Module umgehen 
das Problem, indem der Compiler den Code 
nur einmal einbindet und dennoch durch 
Ausprägung der volle Typcheck gegeben ist. 

Cluster ist darüber hinaus voll objektorien¬ 
tiert, d.h. es verfügt über Klassen, Objekte, 
Methoden, Vererbung, Generizität mit 
Objekten, dynamisches Binden, Mehrfacher¬ 
ben etc. Die Vorteile und Eigenschaften des 
objektorientierten Ansatzes zu erklären, 
sprengt den Rahmen unseres Artikels. Auf 
der Cluster-Demo, die als Diskette zum Heft 
existiert (Seite 114), finden Sie einen aus¬ 
führlichen Aufsatz über objektorientiertes 
Programmieren mit Cluster. 

Wer gleichzeitig mehrere Versionen eines 
Programms benötigt, dem bietet Cluster die 
Möglichkeit, bedingt zu kompilieren. Mit 
Hilfe von Schaltern (Flags) läßt sich festle¬ 
gen, welche Programmteile zu übersetzen 
sind. 

Systemeinbindung 

Zu allen Amiga-Libraries existieren Clu- 
ster-Schnittstellenmodule. Sie besitzen den 
Vorteil, alle Libraries automatisch zu öffnen 
und am Programmende wieder zu schließen. 
In C muß man das oft zu Fuß erledigen. 

Sogar TAG-Listen unterstützt Cluster mit 
dem TAG-Typkonstruktor. Dabei werden 
sowohl die Tags als auch Tag-Werte über¬ 
prüft, ob sie zur Funktion passen. 

Nach den theoretischen Ausführungen fin¬ 
den Sie abschließend ein Listing, das den 
Inhalt eines Verzeichnisses ausgibt und die 
Arbeitsweise von Cluster verdeutlicht. rz 

Quell* und Literaturhinweise 

|l| Von ARexx bis Pascal - Binäre Inflation, AMIGA-Magazin 
11/92. Seite 172 ff. 


1 

1 Dieses Programm gibt den Inhalt eines Verzeichnisses als 

36 

INC(depth); 

2 

Baum aus. Es Erwartet ein Argument über die Shell 

37 

END Before; 

3 

MODULE DirTree; 

38 


4 


39 

1 Veringert die Einrücktiefe, da man ja wieder ein 

5 

FROM Arguments IMPORT Arg,NumArgs; 

40 

1 Unterverzeichnis höher ist. 

6 

FROM InOut IMPORT WriteString,WriteLn,Writelnt; 

41 

PROCEDURE After(t : DirTreePtr); 

7 

FROM DosSupport IMPORT DirTreePtr,byName; 

42 

BEGIN 

8 

FROM Strings IMPORT Dup; 

43 

DEC(depth); 

9 


44 

END After; 

10 

VAR tree : DirTreePtr; i Zeiger einen Directorybaum, 

45 


11 

1 dieser Typ ist im Modul 

46 

BEGIN 

12 

1 DosSupport definiert. 

47 

1 Wendet auf alle Elemente des Baumes die Prozedur 

13 


48 

1 Before an, bevor mit den Söhnen des Baumes 

14 

1 Ausgabe des Directorybaums 

49 

1 weitergemacht wird. After wird aufaerufen, nachdem 

15 

PROCEDURE ShowTree(t ; DirTreePtr); 

50 

l der Sohn bearbeitet worden ist. In unserem Fall ist 

16 

VAR depth : INTEGER := 0; 

51 

1 jeder Sohn ein Unterverzeichnis 

17 

1 Gibt den Eintragsnamen und erhöht die einrücktiefe, 

52 


18 

1 für den Fall, daß er ein Unterverzeichnis ist. 

53 

t.ApplyDepthFirst3ig(Before,NIL,After); 

19 

1 ist dies nicht der Fall, wird dies von After wieder 

54 

END ShowTree; 

20 

i rückgängig gemacht. 

55 


21 

PROCEDURE Before(t : DirTreePtr); 

56 

BEGIN 

22 

BEGIN 

57 

IF NumArgs=l THEN i Check, ob Argument übergeben wurde 

23 

WriteString(Dup("1 ",depth));| Gibt depth-Mal "1" aus. 

58 

tree.Get(Arg(0)); l Directory' in Baum einiesen, wobei das 

24 

WriteString(t.data.name A ); | Gibt den Namen aus, 

59 

! 0-te Argument als Pfad verwendet wird. 

25 

i Füllt die Spalte mit Leezeichen auf. 

60 

tree.Sort(byName); 1 Sortieren des Baumes nach Namen. 

26 

WriteString(Dup(" ",50-2*depth-t.data.name A .len)); 

61 

ShowTree(tree); ! Ausgabe des Bauirres, 

27 

IF t.data.dir THEN 

62 

tree.Delete; ( Löschen des Baumes 

28 

1 Falls es ein Verzeichnis ist, wird dessen Größe 

63 

ELSE 

29 

1 ausgegeben 

64 

WriteStringt'DirTree <Pfad>"); WriteLn; 

30 

Writelnt(t.dirData.fullSize ( 8); 

65 

END; 

31 

ELSE 

66 

END DirTree. © 1993 M&T 

32 

33 

1 Falls es ein File ist, dessen Länge. 

Writelnt(t.data.iength,8); 

Dirtree.mod: Ein einfaches Programm, das den Inhalt 

34 

END; 

eines Verzeichnisses ausgibt. Der Verzeichnisname ist 

35 

WriteLn; 

als Argument zu übergeben. 
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Richtlinien 

Systemkonforme 

Programmierung 

Ein Multitasking-Betriebssystem verlangt vom Programmierer die Ein¬ 
haltung bestimmter Richtlinien - ansonsten verpuffen die Vorteile sang- 
und klanglos im Nebel der Regelverstöße. Hier die Knackpunkte, wor¬ 
auf bei der Programmierung zu achten ist. 


von Rainer Zeitler 

"W"eder Amiga-Programmierer ist gut bera- 

I ten, die von Commodore dogmatisierten 
|l Richtlinien strikt einzuhalten. Ansonsten 
riskiert man Inkompatibilitäten mit künftigen 
Betriebssystemversionen. Die jüngste Ver¬ 
gangenheit hat die Misere deutlich gemacht - 
Anwender mußten damit rechnen, daß seine 
Programme unter anderen Versionen nicht 
laufen. 

Programmierrichtlinien sind eine Seite, die 
andere Kompatibilitätsprobleme, die mit dem 
Erscheinen neuer Betriebssysteme auftreten. 
Der gravierendste Einschnitt geschah mit 
dem Sprung von Betriebssystem 1.3 auf 2.0. 
Spätestens hier trennte sich die Spreu vom 
Weizen, wenn das eine oder andere Pro¬ 
gramm partout nicht funktionieren wollte. 
Anders beim Betriebssystem 3.0, das im 
Amiga 1200/4000 eingebaut ist. Hier darf 
man davon ausgehen, daß nahezu jede Soft¬ 
ware, die unter 2.0 einwandfrei funktioniert, 
auch unter 3.0 läuft. Eine pauschale Aussage 
läßt sich dennoch nicht treffen. 

Generelle Programmier-Richtlinien 

□ Schon Einsteiger kennen einen der 
schlimmsten Verstöße: Die Verwendung von 
festen Betriebssystemadressen. Wer sich in 
einem Multitasking-Betriebssystem darauf 
verläßt, daß bestimmte Funktionen immer an 
der gleichen Stelle im ROM liegen, ist ver¬ 
lassen. So abgedroschen diese Binsenweis¬ 
heit auch klingen mag - hier liegt oft die 
Ursache für fehlerhafte Programme. Die ein¬ 
zige feste Betriebssystemadresse ist 4, über 
die der Einsprung in die »exec.library« 
geschieht. Von dort lassen sich alle Libraries, 
Ressourcen etc. aufspüren. 

□ Ein weiterer, oft anzutreffender Fehler ist 
die Verwendung von nichtinitialisierten Zei¬ 
gern. die meist auf die Speicherstelle Null 
zeigen. Deshalb gilt: Überprüfen Sie vor 
jedem Schreibzugriff via Zeiger, ob er 
gefahrlos erfolgen kann. 

□ Es ist zwingend erforderlich, Speicher oder 
Ressourcen nach Anforderung auch darauf¬ 
hin zu überprüfen, ob der Aufruf erfolgreich 
verlief. Man sieht es nur allzu häufig, daß 


ohne Verifikation vorausgesetzt wird, daß der 
Speicher oder ähnliches bestimmt zur Verfü¬ 
gung steht. Vorsicht! 

□ Geben Sie alle Ressourcen (Speicher, 
Libraries etc.) am Programmende wieder frei. 
Unter Betriebssystem 2.0 und höher ist das 
im übrigen leicht feststellbar: Gehen Sie ins 
Shell/CLI und rufen Sie den Befehl AVAIL- 
mit dem Argument »flush« auf. AVAIL zeigt 
den verfügbaren Speicher an, Flush bewirkt 
zudem, daß alle überflüssigen Libraries aus 
dem Speicher entfernt werden. Starten Sie 
jetzt Ihr Programm. Nach Beendigung tippen 
Sie erneut »avail flush« ein. Die angezeigten 
Werte müssen, sofern alle Ressourcen 
ordentlich dem System zurückgegeben wur¬ 
den, mit den zuvor ermittelten übereinstim¬ 
men. Doch auch wer kein OS 2.0 besitzt, hat 
eine ähnliche Möglichkeit. Starten Sie hierzu 
die Workbench mit dem Argument »-debug«. 
Sie werden einen neuen Menüpunkt »Flush- 
libs« entdecken, der ebendies tut - er entfernt 
nicht benutzte Libraries aus dem Speicher. 
Ein AVAIL-Aufruf bringt dann Klarheit. 

3 Erstaunlicherweise tauchen häufig System¬ 
abstürze bei 32-Bit-Prozessoren auf, die z.B. 
im Amiga 1200/3000/4000 zu finden sind. 
Gerade bei Assembler-Program men ist das zu 
beobachten. Sie laufen prächtig unter Prozes¬ 
soren, die lediglich Speicherbereiche mit 24 
Bit adressieren (z.B. Amiga 500/600/2000), 
da hier die oberen acht Bit unbeachtet blei¬ 
ben. Nicht so beim 32-Bit-Prozessor. Nur ein 
falsches Bit, und die Katastrophe ist unver¬ 
meidlich. Deshalb: Struktur- und Variablen¬ 
bereiche sollten vor der Benutzung immer 
mit Null belegt werden. Zugegeben. Hoch¬ 
sprachenprogrammierer haben's hier einfa¬ 
cher, da diese Arbeit schon von den meisten 
Compilern abgenommen wird. In diesem 
Zusammenhang sei auf folgende Fehlerquel¬ 
len hingewiesen: Vergleichen Sie auf 32-Bit- 
Maschinen Adressen niemals mit vorzeichen¬ 
behafteten Zahlen. Auch der Test auf einen 
Null-Zeiger mit 8- oder 16-Bit-Variablen ist 
tabu. Verwenden Sie immer Variablen vom 
Typ »unsigned long«. 

S Und wieder trifft's die Assembler-Pro¬ 
grammierer. Einem Drahtseilakt vergleichbar 
ist die Angewohnheit, nach einem Funktions¬ 


aufruf des Betriebssystems davon auszuge¬ 
hen, daß die Register DO, Dl, A0 und Al 
unverändert sind. Auch wenn es bei einigen 
so ist - in Zukunft muß das nicht so sein. 
Aufgrund überraschender Fehlfunktionen 
vieler Programme modifizierten die Commo- 
dore-Entwickler schon abgeschlossene Sy¬ 
stemfunktionen insofern, daß die oben ge¬ 
nannten Register nach dem Aufruf wieder 
den gleichen Inhalt besaßen. Verlassen Sie 
sich in künftigen Betriebssystemen nicht dar¬ 
auf, daß ein Betriebssystem an Programme 
angepaßt wird und nicht umgekehrt - para¬ 
dox ist das Ganze jedenfalls schon. 

3 Wenn wir schon bei Assembler-Program- 
mieren sind: Rufen Sie niemals Be¬ 
triebssystemfunktionen auf, ohne zuvor den 
Library-Vektor ins sechste Adreßregister 
(A6) befördert zu haben. Schließlich gehen 
alle Funktionen davon aus, hier die Library- 
Adresse zu finden. Das gilt auch für Funktio¬ 
nen, die den Library-Pointer eigentlich nicht 
benötigen, denn auch das kann in spe ganz 
anders aussehen. 

□ Einige Funktionen älterer Betriebssytem- 
versionen wiesen zwar den einen oder ande¬ 
ren Parameter auf - genutzt wurde er dort 
jedoch nicht. Das ändert sich aber so sicher 
wie das Amen in der Kirche. Wenn auch 
nicht jetzt, so doch bei späteren Versionen. 
Es ist außerordentlich wichtig, diese Parame¬ 
ter korrekt zu initialisieren - und wenn's 
»nur« eine Null ist. Ansonsten kann es später 
zu unangenehmen Folgen führen. 

Für Programmierer 
sind die Richt¬ 
linien bindend 

3 Verwenden Sie niemals mit »private« 
gekennzeichnete Elemente von Systemstruk¬ 
turen (z.B. die »intuition.Library« von OS 
1.3). Das kann einmal gutgehen, ein anderes 
Mal nicht, da das Element z.B. für gänzlich 
andere Aufgaben als ürsprünglich geplant 
eingesetzt wird. 

3 Besondere Vorsicht ist bei Programmen 
mit selbstmodifizierendem Code geboten. 
Der MC68040-Prozessor verfügt über einen 4 
KByte großen Daten- und Instruction-Cache. 
Im schlimmsten Fall greift er auf nicht exi¬ 
stente Daten zu ([1]). Spezielle Funktionen 
der »exec.library«, z.B. CacheClearU() oder 
CachePostDMA(), beugen diesen Fehlern 
vor. Gleiches gilt fürs Trackdisk-Device - 
vor dem Lesen ist der Puffer zu leeren 
(Flush). 

□ Wenn Sie Zeitintervalle oder Pausen in 
Ihrem Programm benötigen - verwirklichen 
Sie das niemals mit Hilfe von Schleifen, die 
soundso oft ausgeführt werden. Erstens steht 
das mit dem Multitasking nicht in Einklang, 
da die Rechenleistung des Amiga in die Knie 
geht, zum anderen sind die Pausen auf dem 
Amiga 3000 kürzer als die auf einem Amiga 
500. Klar, ist der Prozessor doch um einiges 
fixer. Greifen Sie stattdessen auf die elegan- 
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; Die von Commodore empfohlene Resetroutine 

INCLUDE "exec/types.i" 

So geht's: Der richtige Reset per 

INCLUDE "exec/1ibraries.i" 

csect text 
xdef _ColdReboot 

Software ist problemlos möglich - 
am besten mit der von Commo- 

dore empfohlenen Routine. 

xref _LVOSupervisor 

REALEXECBASE equ 4 

Pointer exec.library 

MAGIC_R0MEND equ $01000000 

Ende des Kickstart-ROM 

MAGIC.OFFSET equ -$14 

Offset vom ROM-Ende zur 

Kickstart-Größe 

KICK.V36 equ 36 

Ab Kickstart V36 stellt das 

Betriebssystem eine eigene 

Reset-Routine zur Verfügung 

V36_ColdReboot equ -726 

Offset der Reset-Routine 

_ColdReboot: 

move.1 REALEXECBASE,a6 

exec.library-Pointer in A6 

cmp.w #KICK_V36,LIB_VERSION(a6) 

blt.s old_exec 

KickstartVersion <36 

Der Reset muß selbst aus¬ 
geführt werden 

j mp V3 6_ColdReboot(a6) 

Sonst die Coldreboot- 
Routine anspringen, aus der 
wir niemals zurückkehren 

old_exec: 

lea.I GoAway(pc),a5 

Die Adresse des Reset-Codes 

j sr _LVOSupervisor(a6) 

Den Code ausführen 

; Diesen Punkt erreichen wir nicht mehr 

CNOP 0,4 

Auf Langwort ausrichten 

GoAway: 

lea.1 MAGIC_ROMEND,aO 

ROM-Ende 

sub.1 MAGIC_OFFSET(aO),aO 

berechnen des PC 

move.l 4(a0),a0 

PC beim Einsprung 

subq.l #2,a0 

Zeigt auf den zweiten Reset 

reset 

reset und jmp müssen ein 

jmp (aO) 

Langwort teilen 

END 


ten Möglichkeiten des Timer-Device zurück. 
Es bietet die erforderlichen Funktionen und 
wird auch in Zukunft funktionieren. 

□ Greifen Sie auf Hardwareregister zu, 
initialisieren Sie diese mit Ihren eigenen Ein¬ 
stellungen. Gehen Sie niemals von voreinge¬ 
stellten Werten aus, da sich diese unter neuen 
Betriebssystemversionen ändern können. 

□ ASL-Library hin, ARP-Library her: Seit 
OS 2.0 gibt’s dank der ASL-Library einheitli¬ 
che Datei- und Font-Requester. Demnach ist 
es überflüssig, eigene zu programmieren, 
denn sie sind extrem leistungsfähig. Sicher, 
es gibt zig weitere PD-Libraries, die hier und 
da ihre Vorzüge besitzen; dennoch sollten die 
Programme auf die ASL-Library umgestellt 
werden oder wenigstens eine Option bieten, 
den benutzten Requester zu wählen. 

Kompatibilitätsrisiken unter OS 2.0 

Bei der Umstellung von OS 1.3 auf 2.0 
gab's viele Veränderungen. Einige der wich¬ 
tigsten stellen wir vor: 

□ Amiga-DOS wurde komplett überarbeitet 
und hat die BCPL-Relikte hinter sich gelas¬ 
sen. BCPL brachte die Eigenschaft mit sich, 
daß DOS-Funktionen Rückgaben sowohl 
übers Register DO als auch Dl lieferten. Das 
ist passe. Bis auf wenige Ausnahmen steht 
der Return-Wert nur noch in DO. 

□ Das Audio-Device wird erst dann in den 
Speicher geladen, wenn es benötigt wird. 
Unter Umständen kann das aufgrund man¬ 
gelnden Speichers schiefgehen. Nach dem 
ersten Öffnen und trotz korrekter Freigabe 
aller Ressourcen verlieren Sie Speicher. 
Beim zweiten Aufruf passiert das nicht. 

□ Möchten Sie per Software einen Reset aus- 
lösen, war es unter OS 1.3 (und älter) üblich, 
an den Anfang des ROM-Bereichs 
(0xFC0002) zu springen. Unter dem Amiga 
3000 und unter späteren Betriebssystemver¬ 
sionen funktioniert das nicht mehr. Benutzen 
Sie stattdessen die im Listing abgedruckte 
Assembler-Routine. Sie wird von Commo- 
dore offiziell vorgeschlagen. 

□ Die »intuition.library« hat sich grundle¬ 
gend geändert. Wenn Sie Fenster auf der 
Workbench öffnen, bedenken Sie, daß der 
Workbench-Screen andere Dimensionen, 
mehr Farben und andere Zeichensätze haben 
kann. Außerdem ist es jetzt möglich, daß ein 
Screen negative Ursprungskoordinaten be¬ 
sitzt. Den verwendeten Zeichensatz identifi¬ 
zieren Sie über den Screenpointer der Work¬ 
bench: 

stmct Screen *WBScreen; 

// Der verwendete Zeichensatz 
struct Font *Screenfont= 

WBScreen->RastPort.Font; 

// Die Höhe des Zeichensatzes 
WORD FontHoehe = 

WBScreen->RastPort.TxHeight; 

Die Textbreite kann variieren, falls propor¬ 
tionaler Zeichensatz eingestellt ist. Doch es 
steht immer auch nichtproportionaler Zei¬ 
chensatz zur Verfügung, der via Preferences 
einzustellen ist. Über die »graphics.library« 
ist dieser zu erfahren: 


// Zeiger auf graphics.library 
struct GfxBase *GfxBase; 

// Der eingestellte Monospaced-Font 
struct Font 

*DefaultFont=GfxBase->DefaultFont; 

// Die Höhe des Zeichensatzes 
WORD Fonthoehe= 

GfxBase->DefaultFont->tf_YSize; 

// Die Breite eines Zeichens 
WORD Fontbreite= 
GfxBase->DefaultFont->tf_XSize; 

Gehen Sie niemals davon aus, daß der Zei¬ 
chensatz Topaz 8 eingestellt ist. Tun Sie das 
dennoch, ergeben sich unschöne Effekte und 
der Anwender muß, nur um Ihr Programm 
bedienen zu können, Topaz 8 extra wählen. 

□ Verwenden Sie zudem niemals in Ihrer 
Applikation eine Tastenkombination mit der 
linken Amiga-Taste. Diese ist für System¬ 
zwecke reserviert. 

□ Auch die oft benutzte Funktion GetScreen- 
Data(), mit deren Hilfe sich die Workbench- 
Auflösung und -Dimension einfach kopieren 
ließ, ist nicht empfehlenswert. Benutzen Sie 
stattdessen die Funktionen LockPubScreen() 
und GetVPModeID(), um die Workbench- 
Daten in Erfahrung zu bringen. 

□ Die gemeinsame Angabe der IDCMP- 
Messageflags RAWKEY und VANILLA- 
KEY erzeugt jetzt eine Message vom Typ 
RAWKEY, wenn eine Sondertaste betätigt 
wurde, sonst VANILLAKEY. Der Umweg 
über die Funktion RawKeyKonvert() entfällt. 


□ Auch bei der »graphics.library« sind 
einige Dinge zu beachten. Die Einträge »Dis- 
playFlags«, »row« und »cols« müssen nicht 
mit denen der Workbench übereinstimmen. 
Die ColorMap-Strukur ist größer und sollte 
mit der Funktion GetColorMapO generiert 
werden. Eine beliebte Methode, Bildschirm¬ 
pixel anzusprechen, war die Anwendung der 
Modulo-Funktion auf die Bitmap-Breite. Das 
kann schiefgehen. Sicherer ist es, den Wert 
»BitMap->BytesPerRow« zu nehmen. Im 
übrigen ist es für zukünftige Betriebssysteme 
außerordentlich wichtig, die Bitmap nicht 
über den Eintrag in der Screen-Struktur zu 
erreichen, sondern über den Rastport: 

// Falsch 

struct BitMap *fanap=Screen->BitMap; 

// Richtig 
struct BitMap 

*bmap=Screen->RastPort.BitMap; 

Zu Inkompatibilitäten kann auch die Allo- 
kierung von Bitmaps mit der AllocMem()- 
Funktion führen. Das Reservieren benötigten 
Speichers für Bitmaps ist grundsätzlich mit 
der AllocRaster()-Funktion vorzunehmen. 

Sicher, es gibt weitere mögliche Fehler¬ 
quellen. Beachtet man jedoch die hier vorge¬ 
stellten, spart man sich bereits eine Menge - 
unnötigen - Ärger. ■ 

Literaturhinweise: 

[ 11 Zeitler, Rainer: Programmieren unter OS 2.0 - die »exec.libr- 
ary«, AMIGA-Magazin 6/92. Seite 124 

[2) Commodore-Amiga, ROM Kemel Reference Manual »Hard¬ 
ware«. Third Edition, Addison Wesley 
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Huffman - Codes 

Datenkomprimierung in 

Assembler 


von Sebastian Wedeniwski 

D as Datenkompressionsverfahren von 
D.Huffman kann in Textdateien (und 
vielen anderen Arten von Dateien) 
eine beträchtliche Platzeinsparung ermögli¬ 
chen. Die Huffman-Kodierung wurde 1952 
entdeckt, wobei die Implementation moder¬ 
nere algorithmische Techniken verwendet. 
Folgende Idee steckt hinter dem Verfahren: 

Anstatt die üblichen acht Bits für jedes 
Zeichen zu benutzen, werden für Zeichen, die 
häufig auftreten, nur wenige Bits verwendet, 
und mehr Bits für die, die selten Vorkommen. 

Bei der Kodierung darf kein Zeichencode 
mit dem Anfang eines anderen übereinstim¬ 
men, um nur eine Möglichkeit bei der Deko¬ 
dierung zu gewährleisten (z.B. »A« mit 1, 
»B« mit 01 und »C« mit 00 verschlüsseln). 
Eine einfache Methode zur Darstellung der 
Codes ist die Verwendung eines Trie. 

Gut gepackt } ist viel 
gewonnen 

Ein Trie ist ein modifiziertes Modell des 
digitalen Baums, in dem die Schlüssel nicht 
in Knoten des Baums gespeichert, sondern 
statt dessen in äußeren Knoten des Baums 
angeordnet werden. Infolgedessen sind zwei 
Typen von Knoten vorhanden: 

- Innere Knoten, die nur Verkettungen zu 
anderen Knoten implizieren, und 
- äußere Knoten, die Schlüssel und keine 
Verkettungen implizieren. 

In dieser Struktur wird der Schlüssel 
zufolge seinen Bits abgezweigt (bei 0 nach 
»links« und bei 1 nach »rechts«). Ein digita¬ 
ler Trie für das obenerwähnte Beispiel: 

ABCBA 

kodiert zu: 10100011 

Die einzelnen Schritte bei der Erzeugung 
des Huffman-Codes: 

Im ersten Schritt wird durch Zählen der 
Häufigkeit jedes Zeichens innerhalb der zu 
kodierenden Zeichenfolge ermittelt. Der 
nächste Schritt ist dann der Aufbau des 
Kodierungs-Tries gemäß der Häufigkeit. Der 
Trie wird durch einen binären Baum mit 
Häufigkeit, die in den Knoten gespeichert 
sind, generiert: Vorerst wird für jede von null 
verschiedene Häufigkeit ein Knoten des 
Baums generiert. Anschließend werden die 
beiden Knoten mit den kleinsten Häufigkei- 



Bild: Ein Trie ist eine Abwandlung 
eines binären Baums 


ten ausgesucht und es wird ein neuer Knoten 
generiert, der diese beiden Knoten als Nach¬ 
folger hat und dessen Häufigkeit einen Wert 
hat, der gleich der Summe der Werte für 
seine Nachfolger ist. Danach werden die bei¬ 
den Knoten mit der kleinsten Häufigkeit in 
diesem Wald ermittelt und ein neuer Knoten 
wird auf diese Weise generiert. Letztendlich 
sind alle Knoten miteinander zu einem einzi¬ 
gen Baum vereinigt. 

Jetzt kann der Huffman-Code abgeleitet 
werden, indem die Häufigkeiten an den unte¬ 
ren Knoten einfach durch die zugehörigen 
Buchstaben substituiert werden und der 
Baum dann als ein Trie für die Kodierung 
betrachtet wird. Die vorgestellte Implementa¬ 
tion ist so abgestimmt, daß sie ohne weiteres 
in eigene Programme eingebaut werden kann. 
Diese Implementation besteht aus zwei Tei¬ 
len, der eine Teil »Pack« komprimiert den 
vorgegebenen Speicherbereich und der 
zweite Teil »Unpack« entschlüsselt den Huff¬ 
man-Code und schreibt des Resultat in einen 
vorgegebenen Speicherbereich. Die Handha¬ 
bung läuft wie folgt ab: 

Komprimierung: Die Anfangsadresse des 
Speicherbereichs, der komprimiert werden 
soll, muß im Adreßregister al und die 
Anfangsadresse des Resultats in a2 stehen. 
Die Länge des zu komprimierenden Spei¬ 
cherbereichs muß im Datenregister d7 stehen 
(Tip: d7 sollte zum komprimierten Programm 
beigefügt werden, um den Speicherumfang 
beim Entpacken zu kennen). Nach dem Auf¬ 
ruf von »Pack« müssen zum Resultat die 
Kodierungstabellen »length« (Länge des 
komprimierten Speicherbereichs in Bits), 
»code« (Huffman-Code für jedes Byte) und 
»len« (Länge des entsprechenden »code«) 


beigefügt werden. Diese Codes sind elemen¬ 
tar beim Entpacken. 

Entpacken: Die Anfangsadresse der kom¬ 
primierten Datei muß im Adreßregister aO 
und die Anfangsadresse des Resultats muß in 
a5 stehen. Jetzt kann »Unpack« aufgerufen 
werden. 

Das Datenkomprimierprogramm ist schnell 
(je nach Speicherumfang) und effizient. Zum 
Vergleich haben wir ein Testbild mit der 
Länge von 49428 Byte komprimiert und 
kamen auf 18916 + 772 (Kodierungstabelle) 
Byte. Der »IFF-Packer« kam bei der gleichen 
Datei auf 21786 Byte, d.h. benötigte rund 20 
Prozent mehr Platz für die gepackte Datei, ub 


1: lea a,al ; Anfangsadresse der Quelldatei 
2: lea ziel,a2 ; Anfangsadresse der Zieldatei 
3: move.l #aend-a,d7 ; Quelldateilänge 
4: jsr Pack 

5: lea ziel,aO ; Anfangsadresse der komprimie 
rten Datei 

6: lea a,a5 ; Anfangsadresse der Zieldatei 
7: jsr Unpack 
8: rts 

9: a: incbin "Programmname* ; zu komprimierende 
s Programm 
10: aend: 

11: Pack: 

12: move.l d7,-(sp) 

13: move.l al,-(sp) 

14: move.l a2,-(sp) 

15: lea count(pc),aO 

16: subq.l #l,d7 

17: Anzahl: moveq #0,d0 

18: move.b (al,d7.i),d0 

19: add.w d0,d0 

20: add.w d0,d0 

21: addq.l #l,(a0,d0.w) 

22: dbra d7,Anzahl 
23: moveq #0,d0 
24: move.l d0,d7 
25: move.l a0,a2 
26: lea heap(pc),a3 
27: Loop2: tst.l <a2)+ 

28: beq.s Loop 
29: addq.w #2,d0 
30: move.w d7,(a3)+ 

31: Loop: addq.w #4,d7 

32: cmp.w #$400,d7 

33: bne.s Loop2 

34: lea heap(pc),a3 

35: move.l d0,d6 

36: move.l dO,dl 

37: lsr.w #l,dl 

38: down: move.w d6,d7 

39: move.w -2(a3,d7.w),d2 

40: bsr downheap 

41: subq.w #2,d6 

42: bne.s down 

43: lea dad(pc),a4 

44: repeat: move.w (a3),d6 

45: move.w -2(a3,d0.w),(a3) 

46: subq.w #2,d0 
47: moveq #2,d7 
48: move.l d0,dl 
49: lsr.w #l,dl 
50: move.w (a3),d2 
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bsr downheap 
move.w (a3) r d2 
move.l (a0,d2.w),d3 
add.l (a0,d6.w),d3 
move.l d0,d7 
add.l d7,d7 
move.l d3,-4(a2,d7.w) 
add.l #$3fc,d7 
move.l d7,(a4,d6.w) 
move.w d7,(a3) 
neg.l d7 

move.l d7,(a4,d2.w) 
moveq #2,d7 
move.w (a3),d2 
bsr downheap 
cmp.w #2,dO 
bne.s repeat 
clr.l $400(a4) 
lea code(pc),a2 
lea len(pc),a3 
moveq #0,d7 
for: moveq #-l,d0 
tst.l (a0)+ 
bne.s Weiter2 
clr.w (a2)+ 
move.b dO,(a3)+ 
bra.s next 
Weiter2:moveq #l,dl 
moveq #0,d3 
move.l (a4,d7.w),d2 
repeat2:bge.s ben 
add.l dl,d3 
neg.l d2 

ben: add.l dl,dl 
addq.l #l,d0 
move.l (a4,d2.w),d2 
bne.s repeat2 
move.w d3,(a2)+ 
move.b dO,(a3} + 
next: addq.w #4,d7 
cmp.w #$400,d7 
bne.s for 
move.l (sp)+,a0 
move.l (sp)+,a2 
add.l (sp)+,a2 
lea len(pc),a3 
lea code(pc),a4 
moveq #0,d7 


move.l d7,d0 
move.l d7,d6 
move.l d7,d2 
for2: moveq #0,dO 
move.b (al)+,d0 
moveq #0,dl 
move.b (a3,d0.w),dl 
add.w d0,d0 
lea 1(a4,d0.w) ,a5 
rueck: cmp.b #8,dl 
blt.s rueck2 
move.b dl,d2 
subq.b #8,d2 
btst d2,-l(a5) 
bra.s wtw 

rueck2: btst dl,(a5) 
wtw: beq.s wt 
bset d7,(a0> 
wt: addq.l #1,d6 
addq.b #l,d7 
and.b #7,d7 
bne.s wet 
addq.l #l,a0 
wet: dbf dl,rueck 
cmp.l al,a2 
bne.s for2 
subq.l #l,d6 
lea length(pc),a0 
move.l d6,(a0) 
rts 

downheap: 
cmp.w dl,d7 
bgt.s Weiter 
move.l d7,d3 
add.w d3,d3 
cmp.w d0,d3 
bge.s Sprung 
lea -2(a3,d3.w),a5 
move.w (a5)+,d4 
move.w (a5),d5 
move.l (a0,d5.w),d5 
cmp.l (a0,d4.w),d5 
bge.s Sprung 
addq.w 12,d3 

Sprung: move.w -2(a3,d3.w),d4 
move.l (a0,d4.w),d5 
cmp.l (a0,d2.w),d5 
bgt.s Weiter 


: move.w d4,-2(a3,d7.w) 

: move.w d3,d7 

: bra.s downheap 

: Weiter: move.w d2,-2(a3,d7.w) 

: rts 

: heap: dcb.w 256,0 
: count: dcb.l 2*256,0 
: dad: dcb.l 2*256,0 
: Unpack: 

: move.l length(pc),d4 ; komprimierte Dateilä 
nge in Bits 
lea code(pc),a3 
moveq #0,d0 
move.l d0,d6 
move.l d0,d5 
re: btst Ö6,(aO) 
beq.s nicht 
addq.b #1,dO 
nicht: addq.b #1,d6 
and.b #7,d6 
bne.s nicht2 
addq.l #l,a0 
nicht2: moveq #0,d7 
lea len(pc),a2 
11: cmp.b (a2)+,d5 
bne.s 12 
move.w d7,dl 
add.w dl,dl 
cmp.w (a3,dl.w),d0 
bne.s 12 
moveq #0,d0 
move.b #-l,d5 
move.b d7,(a5)+ 
move.b d5,d7 
12: addq.b #l.d7 
bne.s 11 
add.w d0,d0 
addq.b #l,d5 
dbf d4,re 
rts 

length: dc.l 0 ; komprimiertes Programm 
Code: dcb.w 256,0 
len: dcb.b 256,0 

ziel: dcb.b aend-a,0 : © 1993 M&T 
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Angewandte Mathematik 

Differenzieren 


Das Ableiten von Funktionen ist. 
für viele ein rotes Tuch. Doch 
gerade in der Mathematik findet 
man viele Beispiele, komplexe 
Lösungsverfahren mit dem Com¬ 
puter einfach und effizient umzu¬ 
setzen. Und zum Glück gehört das 
Ableiten von Funktionen dazu. 

von Markus Öllinger 

E in Computer ist in vielerlei Hinsicht 
für den Menschen eine Unterstützung. 
Eine seiner herausragenden Leistungen 
ist es, Berechnungen in einer für menschliche 
Verhältnisse ungewöhnlichen Geschwindig¬ 
keit durchzuführen. Mit ihm läßt sich viel 
Zeit für die Lösung schwieriger Rechnungen 
einsparen. Ein weiterer Vorteil ist die Eigen¬ 
schaft korrekter Algorithmen (Programme), 
daß sie immer ein korrektes Ergebnis liefern. 
Rechenfehler können beim funktionstüchti¬ 
gen Computer ausgeschlossen werden. 

Programme, die mathematische Berech¬ 
nungen übernehmen, haben meist einen 
Nachteil: Sie sind kompliziert. Selbst 
Rechenaufgaben, die für den kopfrechnenden 
Menschen einfach sind, können einen Pro¬ 
grammierer hier und da zur Verzweiflung 
bringen. Trotzdem lohnt sich meist der Auf¬ 
wand und deshalb wollen wir uns hier mit 
einer Rechenart beschäftigen, die wohl jeder 
fortgeschrittene Gymnasiast schon genossen 
haben dürfte: dem Differenzieren. 

Der Amiga kann von sich aus nicht diffe¬ 
renzieren. Wir müssen ihm Schritt für Schritt 
beibringen, was beim Differenzieren einer 
Funktion alles zu erledigen ist. Dazu aber 
müssen wir selbst differenzieren können, 
ansonsten dürfte es schwer fallen, den Com¬ 
puter via Programmiersprache zu instruieren. 

Es ist nicht einfach, den Vorgang in ein 
Programm zu fassen. Wir wissen jedoch, daß 
das Differenzieren nach einem bestimmten 
Schema abläuft. Es muß demzufolge ein 
Algorithmus existieren, der alle differenzier¬ 
baren Funktionen ableiten kann. Das macht 
Zuversicht. Anders sieht das bei der Umkeh¬ 
rung der Ableitung aus, dem Integrieren. 
Legen wir also zuerst fest, was unser Pro¬ 
gramm alles leisten soll: 

Wir benötigen eine Funktion (nennen wir 
sie »Diff«), der wir eine Zeichenkette mit der 
zu differenzierenden Formel übergeben und 
die uns eine neue Zeichenkette mit der dazu¬ 
gehörigen Ableitung liefert. Unterstützt wer¬ 
den dabei die üblichen mathematischen Ope¬ 
ratoren »(«, »)«, »+«, »-«, »*«, »/«, » A « 


sowie diverse Winkelfunktionen. Es ist klar, 
daß wir mit der gegebenen Repräsentation 
der Funktion in Form einer Zeichenkette 
(String) wenig Freude haben werden. Der 
erste Schritt besteht nun darin, die Funktion 
in anderer Form zu speichern, die für unsere 
Aufgabe besser geeignet ist: als Baum. 

Betrachten Sie zunächst das Bild des 
Binärbaums. Er besteht aus einzelnen Kno¬ 
ten, in der Abbildung als kleine Kreise darge¬ 
stellt, die durch sog. Kanten miteinander ver¬ 
bunden sind. In der Informatik wachsen 
Bäume von oben nach unten. Der obere Kno¬ 
ten wird deshalb als Wurzel bezeichnet, die 
Knoten am unteren Ende als Blätter. Wie Sie 
sehen, speichern wir die Operanden immer 
als Blätter und die dazugehörigen Operatoren 
als innere Knoten. Um nun eine Funktion in 
einem Baum abzulesen, müssen wir die Kno¬ 
ten von links nach rechts auslesen und haben 
die ursprüngliche Funktion wieder. 

Wir wissen jetzt, wie wir unsere Formel 
ablegen. Der nächste Schritt ist, einen Algo¬ 
rithmus herzuleiten, der die Konvertierung 
eines Strings in so einen Binärbaum über¬ 
nimmt. Selbstverständlich muß dieser Pro¬ 
grammteil auch die Prioritäten der mathema¬ 
tischen Operatoren sowie die Auswertung 
von Klammem berücksichtigen. Wir gehen 
dazu wie folgt vor: Wir verwenden zwei Sta¬ 
pel, einen für die Operatoren (+, - usw.), 
einen zweiten für die Operanden, auf die sich 
die Operatoren beziehen. Wir scannen die 
Zeichenkette zeichenweise durch. Dabei 
unterscheiden wir folgende Fälle: 

□ Wir treffen auf einen Operanden: Wir 
legen ihn auf den Operanden-Stack. 

□ Wir treffen auf eine öffnende Klammer 
»(«: Diese legen wir auf den Operator-Stack. 

□ Wir treffen auf einen anderen Operator: 
Hier werden alle Operatoren mit höherer oder 
gleicher Priorität als der zuvor gefundenen 
auf dem Operator-Stapel vom Stapel geholt, 
bis der Stapel leer ist oder eine öffnende 


Klammer erscheint (»(«). Anschließend wird 
der neu im String gefundene Operator auf 
den Operator-Stapel geschoben. 

□ Nach einer schließenden Klammer »)« 
werden alle Operatoren unabhängig von ihrer 
Priorität vom Stapel geholt, bis wir eine öff¬ 
nende Klammer finden. 

□ Am Ende der Zeichenkette werden alle 
Operatoren vom Stack geholt, bis er leer ist. 

Mit allen vom Stapel geholten Operatoren 
wird die Routine »verwende_Operator« auf¬ 
gerufen. Bei einem binären Operator holt sich 



Die Repräsentation der Funktion 
»5*x+x A 2« als binärer Baum 


verwende_Operator zwei Operanden vom 
entsprechenden Stapel, hängt sie als rechten 
und linken Sohn des Operator-Knotens an 
und schiebt anschließend den Operator-Kno¬ 
ten auf den Operanden-Stapel. Bei unären 
Operatoren (z.B. negatives Vorzeichen) wird 
nur ein Operand geholt und als rechter Sohn 
an den Operator angehängt. So wird der 
Baum stückweise zusammengesetzt. 

Um die Wirkungsweise dieses Algorith¬ 
mus zu veranschaulichen, führen wir uns das 
Beispiel aus unserem Bild vor Augen und 
konstruieren den dazugehörigen Baum zu 
Fuß. Die Tabelle zeigt, wie der fertige Baum 
entsteht. Beachten Sie, daß die Formeln im 


TABELLE 

Schritt 

Operanden-Stapel 

Operator-Stapel 

Bemerkung 

1.5 

5 


Operand auf Stapel 

2. * 

5 

* 

Operator auf Stapel 

3. x 

5, x 

* 

Operand auf Stapel 

4. + 

5*x 


Verwende »*« 



+ 

Operator auf Stapel 

5. x 

5*x, x 

+ 

Operand auf Stapel 

6. A 

5*x, x 

+, a 

Operator auf Stapel 

7.2 

5*x, x, 2 

+, a 

Operand auf Stapel 

8. Stringende 

5*x,x A 2 

+ 

Verwende » A « 


5*x+x A 2 


Verwende »+« 
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KNOW-HOW 

■■■■■■■■■■■■■■■■■■■ 


■HHiHHRHn 


Operanden-Stapel keine Zeichenketten, son¬ 
dern schon Teilbäume sind, die von ver- 
wende_Operator gebildet wurden. Aus der 
Tabelle ist ersichtlich, daß sich der Baum am 
Ende auf dem Operanden-Stapel befindet. 
Eine Eigenschaft solcher Bäume ist, daß sie 
keine Klammern enthalten. Sie sind, wie bei 
Postfix-Ausdrücken, implizit in der Baum¬ 
struktur enthalten, indem geklammerte Aus¬ 
drücke einfach tiefer im Baum erscheinen. 

Nachdem die Funktion in eine passende 
Form gebracht ist, wird der Baum zum Diffe¬ 
renzieren, beginnend bei der Wurzel, abgear¬ 
beitet. Dabei bestimmt der Operatorknoten, 
welche Ableitungsregel zum Einsatz kommt. 

Bevor wir mit der Realisierung beginnen, 
setzen wir uns zunächst mit dem Problem 
auseinander, wie bestimmte Operatoren zu 
differenzieren sind. Wir führen hierzu fol¬ 
gende Konvention ein: 

□ u repräsentiert immer den linken Operan¬ 
den eines Operators, 

□ v immer den rechten. 

Beispiel: »5*x« bedeutet, daß u die Zahl 
»5« repräsentiert, v das Symbol »x«. Weiter¬ 
hin vereinbaren wir, daß u differenziert a lau¬ 
ten soll, v hingegen b. Beginnen wir mit der 
Unterscheidung (abhängig vom Operator): 

□ Wir treffen auf ein »+« oder »-«: Hier 
haben wir es nicht schwer. Wir differenzieren 
einfach den Teil links und rechts vom Opera¬ 
tor und sind fertig. Aus u+v wird also a+b. 

□ Wir finden ein »*« vor: Hier kommt die 
Produktregel zum Einsatz: aus u*v wird 
a*v+b*u. 

□ Wir treffen auf ein »/«: Hier verwenden 
wir die Quotientenregel: (a*v-b*u)/v A 2. 

□ Wir treffen auf ein » A «: Die anzuwendende 
Regel ist nicht so einfach und fehlt auch in 
den meisten Formelsammlungen. Deshalb die 
kurze Herleitung: Zuerst formen wir »u A v« in 
»exp(ln(u A v))=exp(v*ln u)«. Nun differenzie¬ 
ren wir diesen Ausdruck nach der Ketten- 
und Produktregel und erhalten: »exp(v*ln 
u)*(b*ln u+a/u*v)=u A v*(b*ln u+a/u*v)«. 

Somit hätten wir die wichtigsten Formeln 
zum Differenzieren - geordnet nach den ein¬ 
zelnen Operatoren - und können nun die 
Arbeitsweise des eigentlichen Differenzier¬ 
teils angehen. Wie Sie gleich sehen werden, 
handelt es sich dabei um einen rekursiven 
Algorithmus. Darunter versteht man eine 
Programmiermethode, bei der sich eine 
Funktion selbst aufruft. Betrachten wir, wie 
mit Rekursion der Ableitungsvorgang schnell 
und relativ einfach zu lösen ist: 

Wir beginnen bei der Wurzel des Baums 
und rufen die Routine »Differenziere« mit 
der Wurzel als Argument auf. Handelt es sich 
um eine Konstante oder Variable, wird sie 
einfach differenziert (Konstante wird 0, 
Variable x wird 1). Andernfalls differenziert 
die Routine zuerst ihren linken Teilbaum 
(entspricht dem Term links vom Operator, 
also u), anschließend ihren rechten Teilbaum 
(also v). So erhalten wir a und b, also die 
Ableitungen von u und v. Wir müssen jetzt 
nur noch die Terme entsprechend den oben 
angegebenen Regeln zusammensetzen. 


Anschließend ist noch das Umwandeln des 
so entstandenen Baums in einen String vor¬ 
zunehmen. Das ist ebenfalls ein rekursiver 
Vorgang. Prinzipiell sieht die Vorgehens¬ 
weise so aus, daß wir wieder bei der Wurzel 
beginnen und zuerst den linken Teilbaum, 
dann den Knoten selbst und anschließend den 
rechten Teilbaum ausgeben. Diese Art der 
Baumausgabe nennt man auch symmetrische 
Reihenfolge. Damit ist es jedoch noch nicht 
getan, denn wir müssen auch die (im Baum 
nicht mehr enthaltenen) Klammem wieder¬ 
herstellen. Das ist jedoch einfach, reicht es 
doch aus, die Prioritäten der Operatoren zu 
vergleichen. In einem Term ohne Klammem 
besitzt der Vater immer einen Operator nied¬ 
rigerer Priorität als seine Söhne (Bild). Hat 
irgendwo im Baum der Operator des Vaters 
eine höhere Priorität als der des Sohns, ist 
eine Klammer zu setzen. Bei gleicher Prio¬ 
rität ist nur nach nicht kommutativen Opera¬ 
toren eine Klammer nötig, um Terme wie »5- 
(x+2)« richtig zu verarbeiten. 

Abschließend werfen wir einen Blick auf 
unser Beispiellisting, in dem alles Bespro¬ 
chene als Programm verwirklicht ist. Nach¬ 
dem eine kurze (nicht vollständige) Überprü¬ 
fung des Terms auf Korrektheit stattgefunden 
hat, sorgen die Routinen »Baum_aufbauen« 
und »verwende_Operator« für die Erzeugung 
des Baums. Anschließend wird die Funktion 
»Differenziere« aufgerufen, die den Baum 
ableitet. Interessant ist die Prozedur 
»Regeln«, die einen Term nach einer von uns 
hergeleiteten Regeln konstruiert. Die Routine 
erhält die Differenzierregeln in einer eigenen 
Schreibweise, der Präfix-Notation. Diese 
zeichnet sich dadurch aus, daß dabei der 
Operator immer vor seinen Operanden steht. 
Der Infix-Term »5*x+x A 2« lautet in Präfix- 
Notation »+*5x A x2«, die Produktregel also 
»+*av*bu«. Aus so einem Term ist (wie¬ 
derum per Rekursion) mit Leichtigkeit ein 
Baum zu erzeugen, da ein Präfixterm genau 
die Reihenfolge angibt, die der Baum von 
oben nach unten beschreibt. 

Z.Zt. unterstützt das Programm die mathe¬ 
matischen Funktionen ln, exp, sin, cos, sinh 
und cosh. Eine Erweiterung um andere Funk¬ 
tionen stellt kein Problem dar, da hierzu nur 
die neuen Funktionsnamen und deren Ablei¬ 
tungsregeln in die Felder »Funktion« und 
»dFunk« einzutragen sind. Genaueres ist der 
Dokumentation des Listings zu entnehmen. 

Das Listing stellt eine anschauliche, ein¬ 
fach gehaltene Lösung des Differenzierpro¬ 
blems dar. Da es keine Vereinfachungen 
(Optimierungen) durchführt, geraten selbst 
einfache Funktionen schnell zu aufgeblähten, 
unübersichtlichen Formeln. Auf der Diskette 
zum Heft finden Sie neben diesem Listing 
das Programm »How-To-Derive«, das neben 
der angesprochenen Vereinfachung eine wei¬ 
tere Besonderheit bietet: Es erklärt dem 
Benutzer Schritt für Schritt, wie die angege¬ 
bene Funktion zu differenzieren ist. Dazu ist 
lediglich die gewünschte Funktion in das 
dafür vorgesehene String-Gadget einzugeben. 
Zudem unterstützt How-To-Derive 20 mathe¬ 


matische Funktionen und ist einfach zu 
bedienen. Wegen der detaillierten Erklärun¬ 
gen stellt es nicht nur eine Arbeitserleichte¬ 
rung dar, sondern ist auch als Lemprogramm 
zum Differenzieren geeignet. Viel Spaß beim 
Ableiten. rz 


1 

: /* Differenzieren mathemat. Ausdrücke */ 

2 

3 

: /‘von Markus Öllinger */ 

4 

5 

6 

7 

8 
9 

: #include <ctype.h> 

: #include <string.h> 

: #include <stdio.h> 

: tinclude <stdlib.h> 

: typedef enum {0P_0PEN=-2,0P_CL0SE,0P_N0N 

E=0,0P_ADD,0P_SUB,OP MUL,OP DIV,0P NiG,0 

P_POT,0P_FUNC1} OP; 



10 


11 

: struct Knoten { 

12 

: struct Knoten *l,*r; 

13 

: OP Operator; 

14 

: short int Pri; 

15 

: short int Len; 

16 

: char ‘Term; 

17 

: ); 

18 


19 

: struct Knoten ‘Neuer_Operand(char *cp,ch 
ar **x); 

20: void verwende_Operator(OP); 

21: struct Knoten *Dif£erenziere(struct Knot 


en *); 

22 : 

23 

extern char *Funktion[); 

24 


25 

OP operator_stack[1024]; 


/* Op.-Stapel */ 

26: mt sp_operator; 


/* Sein Stapelzeiger */ 

27 

struct Knoten *operand_stack[1024]; 

28 

int sp_operand; 

29 


30 

/* wandle Operatorenzeichen in Token */ 

31 

OP Operator(int op) 

32 

{switch(op) { 

33 

case ' +': retum 0P_ADD; 

34 

case ’ -': retum OP_SUB; 

35 

case '*': retum 0P_MUL; 

36 

case 7': retum OP DIV; 

37 

case : retum 0P_NEG; 

38 

case ’ A ’: return OP POT; 

39 

} 

40 

return 0 ; 

41 

) 

42 


43 

/* bestimme Priorität des Operators */ 

44 

Pri(OP op) 

45 

{ 

46 

switch(op) { 

47 

case OP_ADD: 

48 

case 0P_SUB: retum 1; 

49 

case OP_MUL: 

50 

case 0P_DIV: retum 2; 

51 

case 0P_NEG: return 3; 

52 

case 0P_P0T: return 4; 

53 

case 0P_N0NE: return 0; 

54 

default: return 5; 

55 

} 

56 

} 

57 


58 

/* konstruiere Baum aus String */ 

59 

60 

struct Knoten *Baum_aufbauen(char *term) 

61 

(cnar *cp=term; 

62 

int i,l,pri,p; 

63 

OP op,op2; 

64 

char c; 

65 


66 

while((c=*cp)!=0) { 

67 

i f (c==' (') operator_stack [ sp operator+ 

+]=OP OPEN; 

68 

eise if(isalnum(c)) { 

69 

if(isalpha(c)) { 

70 

for(i= 0 ;Funktion[i];i++) 

71 

if (Istmcmp (Funktion [ij, cp, l=strlen 


(Funktion[i]))) { 

72: 

pri=5; 

73: 

op=OP_FUNCl+i; 

74: 

cp+=l-l; 

75: 

goto operator; 

76: 

} 

77: 

} 
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78: 

operand_stack[sp_operand++]=Neuer_0pe 
rand(cp,&cp); 

79: 

cp-; 

80: 

} 

81: 

eise if (c==*)') 

82: 

for(;;) { 

83: 

if(!sp_operator) goto error; 

84: 

op=operator_stack[--sp_operator); 

85: 

if(op!=OP OPEN) verwende Operator(op 

); 

eise break; 

86 

87 

} 

88 

eise { 

89 

op=Operator(c); 

90 

91 

pri=Pri(op); 

92 

93 

/* Subtraktion oder Negation? */ 

94 

if(op==OP_SUB && (cp==term II cp[-l]= 

=•(')) { 

95 

op=OP_NEG; 

96 

pri=3; 

97 

} 

98 

operator: /* verwende alle Operatoren hö 
herer Priorität */ 

99 

whi 1 e(sp_operator) { 

100 

op 2 =operator_stack[sp_operator-l]; 

101 

102 

p=Pri(op2); 

103 

104 

/* Prioritätsvergleich. Achtung A ist 
rechtsassoziativ */ 

105 

if(op2==OP_OPEN 11 p<pri 11 p==pri & 

& p==4) 

106 

break; 

107 

—sp_operator; 

108 

verwende Operator(op2); 

109 

} 

110 

operator stack[sp_operator++]=op; 

111 

} 

112 

cp++; 

113 

} 

114 

while(sp_operator) { 

115 

op 2 =operator_stack[—sp_operator]; 

116 

if(op2==OP_CLOSE) goto error; 

117 

verwende Operator(op2); 

118 

} 

119 

if(sp_operand!=l) goto error; 

120 

retum operand_stack[—sp_operand] ; 

121 

error: 

122 

retum NULL; 

123 

} 

124 


125 

/* gibt Baum wieder frei (rekursiv) */ 

126 

void Baum abbauen(struct Knoten *k) 

127 

{if(k) { 

128 

if(k->1) Baum_abbauen(k->l); 

129 

if(k->r) Baum abbauen(k->r); 

130 

free(k); 

131 

} 

132 

133 

} 

134 

/* Hilfsroutinen */ 

135 

struct Knoten *Neuer_Knoten(void) 

136 

{struct Knoten *k=malloc(sizeof(struct K 
noten)); 

137 

: if(k==NULL) { 

138 

: fprintf(stderr,"Speicher voll! \n' ); 

139 

: exit( 10 ); 

140 

: ) 

141 

: memset((void ‘)k, 0 ,sizeof(*k)); 

142 

: retum k; 

143: } 

144: 

145 

: struct Knoten *Neuer_Operand(char *cp,ch 
ar **x) 

146: {struct Knoten *k; 

147 

: char *s; 

148 

: k=Neuer_Knoten(); 

149 

: s=cp; 

15C 

: while(*++s=='.' II isalnum(*s)); 

151 

: k->Term=cp; 

152 

: k->Len=s-cp; 

153 

: *x=s; 

154 

: retum k; 

155: } 

156: 

157: char *Op(OP op) 

158: {static char c[]={* +-*/- A '}; 

159: if (op>=OP_FUNCl) retum Funktion [op-OP_ 
FUNC1]; 

160: retum &c[op]; 

161: } 

162: 

163: struct Knoten ‘Neuer_Operator(OP op) 

164: {struct Knoten *k; 

165: k=Neuer_Knoten(); 


166: k->Operator=op; 

167: k->Pri=Pri(op); 

168: k->Term=Op(op); 

169: k->Len=op>=OP_FUNCl?strlen(k->Term):1s 
170: retum k; 

171: } 

172: 

173: /* holt ein o. zwei Operanden vom Stapel 

174: * verknüpft sie mit angeg. Operator und 

175: * legt Ergebnis wieder zurück. */ 

176: 

177: void verwende_Operator(OP op) 

178: {struct Knoten *k; 

179: int p=Pri(op); 

180: 

181: k=Neuer_Operator(op); 

182: k->r=operand_s tack(--sp.operand]; 

183: switch(p) { 

184: case 1: 

185: case 2: 

186: case 4: 

187: k->l=operand_stack[—sp_operand]; 

188: k->Operator=op; 

189: k->Pri=p; 

190: break; 

191: } 

192: operand_stack(sp_operand++]=k; 

193: } 

194: 

195: /* erzeugt eine Kopie des Baums */ 

196: struct Knoten *BaumKopie(struct Knoten * 
k) 

197: {struct Knoten ‘n=NULL; 

198: if(k) { 

199: n=Neuer_Operator(OP_NONE); 

200 : *n=*k; 

201: n->l=BaumKopie(k->l); 

202: n->r=BaumKopie(k->r); 

203: } 

204: retum n; 

205: ) 

206: 

207: /* Geht die in 'Regel* gespeicherte Diff 
erenzierregel durch. 

208: * Diese ist in Präfixform gespeichert u 

nd hat folgende Syntax: 

209: * u entspricht dem linken Operanden (ni 

cht differenziert) 

210: * a entspricht dem linken Operanden (ab 

er differenziert) 

211 : * v und b dasselbe rechts 

212 : * + - * / A entsprechen den jeweilgen 0 

peratoren. 

213: * _ entspricht dem (unsren) Negationsop 

erator (Minus-Vorzeichen) 

214: * #XX entspricht einer Funktion, XX gib 

t die Funktionsnummer an. 

215: * #01 ist die Funktion mit dem im Felde 

lement Funktion[0] 

216: * gespeicherten Namen (hier ln), #02 en 

tspr. Funktion[1] usw. 

217: * Eine Ziffer steht für die angegebene 

Zahl. 

218: * 

219: * in u, v, a und b werden die 

220: * gleichnamigen Teilbäume erwartet. V 

221 : 

222: char ‘Regel; /‘zu verwendende Regel*/ 
223: struct Knoten *u,*v,*a,*b; 

224: 

225: /* Hier sind sie: die Differenzierregeln 
für 

226: * + - * / Negation und A . */ 

227: 

228: char *dRegeln[]={ 

229: NULL,'+ab','-ab',*+*av*bu',"/-*av*bu A v2 

230: '_b','* A uv+*b#01u*/vua'}; 

231: 

232: /* Die Funktionsnamen und die Regeln für 
die Ableitung */ 

233: char ‘Funktion[] = {'ln*,'sinh',"cosh\ 'si 
n\ *cos", 

234: "exp',NULL}; 

235: char *dFunk[]={'/bv', '*#03vb\ "*#02vb\ ' 
*#05vb','*_#04vb", 

236: '*#06vb'}; 

237: 

238: struct Knoten ‘Regeln(void) 

239: {struct Knoten *k; 

240: int d; 

241: 

242: switch(d=*Regel++) { 

243: case 'a': k=BaumKopie(a);break; 

244: case 'b': k=BaumKopie(b);break; 

245: case 'u': k=BaumKopie(u);break; 


246: case ’v': k=BaumKopie(v);break; 

247: case : k=Neuer_Operator(OP_NEG);k-> 

r=Regeln();break; 

248: case '#‘: /* Funktion */ 

249: sscanf(Regel,*%d',&d); 

250: Regel+=2; 

251: k=Neuer_Operator(d+OP_FUNCl-l); 

252: k->r=Regeln(); 

253: break; 

254: default: 

255: if(isdigit(d)) { /* Zahl */ 

256: k=Neuer_Knoten(); 

257: k->Term=Regel-l; 

258: k->Len=l; 

259: } eise { /* Operator */ 

260: k=Neuer_Operator(Operator(d)); 

261: k->l=Regeln(); 

262: k->r=Regeln(); 

263: } 

264: } 

265: retum k; 

266: } 

267: 

268: /* erledigt das Differenzieren mittels R 
ekursion */ 

269: struct Knoten ‘Differenziere(struct Knot 
en *k) 

270: {static char One=’l',Zero='0'; 

271: struct Knoten *d; 

272: 

273: if(k->Operator==OP_NONE) { /* Blatt (O 

perand) */ 

274: d=Neuer_Knoten{); 

275: if(k->Len==l && k->Term[0]=='x') 

276: d->Term=&One; 

277: eise d->Term=&Zero; 

278: d->Len=l; 

279: retum d; 

280: } 

281: if(k->Operator>=OP_FUNCl) { /* Funktion 

*/ 

282: b=Differenziere(k->r); 

283: v=k->r; 

284: Regel=dFunk[k->Operator-OP_FUNC1]; 

285: d=Regeln(); 

286: Baum_abbauen(b); 

287: retum d; 

288: } 

289: 

290: /* Operator */ 

291: if(k->l) d=Differenziere(k->l); 

292: eise d=NULL; 

293: b=Differenziere(k->r); 

294: a=d; 

295: u=BaumKopie(k->l); 

296: v=BaumKopie(k->r); 

297: Regel=dRegeln(k->Operator]; 

298: d=Regeln(); 

299: Baum_abbauen(u); 

300: Baum_abbauen(v); 

301: Baum_abbauen(a); 

302: Baum_abbauen(b); 

303: retum d; 

304: } 

305: 

306: /* Baum zurück in String umwandeln */ 
307: /* hat der Vater v einen Sohn s mit eine 
m Operator 

308: * niedrigerer Priorität? */ 

309: 

310: pri_klammer(struct Knoten *v,struct Knot 
en *s,char **sp) 

311: {if(v->Pri>s->Pri && s->Pri!=0 II v->Pri 
==s->Pri && v->Pri==4) { 

312: (*sp)[0]='('; 

313: (*sp)++; 

314: retum 1; 

315: } 

316: retum 0; 

317: } 

318: 

319: /* mach ev. Klammer wieder zu */ 

320: void klammer_zu(char “sp,int kl) 

321: {if(kl) { 

322: (*sp)[0]=')'; 

323: (*sp)++; 

324: } 

325: } 

326: 

327: void Baum_zu_String(struct Knoten *k,cha 
r *s) 

328: {extern char *Baum_String(struct Knoten 
*,char *); 

329: *Baum_String(k,s)=0; 

330: } 

331: 

332: char *Baum_String(struct Knoten *k,char 
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*s) 

333 

{int kl; 

334 


335 

if(k->0perator==0P_N0NE) { 

336 

strncpy(s,k->Term,k->Len); 

337 

s+=k->Len; 

338 

retum s; 

339 

} 

340 

if(k->Operator>=OP_FUNCl) { 

341 

strncpy(s,k->Term,k->Len); 

342 

s+=k->Len; 

343 

kl=pri_kiammer(k,k->r,&s); 

344 

if(!kl) *s++r' 

345 

s=3aum_String(k->r,s); 

346 

klammer_zu(&s,kl); 

347 

retum s; 

348 

} 

349 

if(k->0perator==0P_NEG) { 

350 

*s++='-'; 

351 

kl=pri_klammer(k,k->r,&s); 

352 

s=Baum_String(k->r,s); 

353 

klammer_zu(&s,kl); 

354 

retum s; 

355 

} 

356 

kl=pri_klammer(k,k->l,&s); 

357 

if(!kl && k->0perator==0P_P0T && k->l-> 
0perator==0P_P0T) { 

358 

*s++='('; 

359 

kl=l; 

360 

} 

361 

s=Baum_String(k->l,s); 

362 

klammer zu(&s,kl); 

363 

*s++=* 0 p(k-> 0 perator); 

364 

kl=pri_klammer(k,k->r,&s); 

365 

if(!kl && (k->0perator==0P_SUB II k->0p 
erator==0P DIV) && k->r->Pri==k->Pri) { 

366 

('? 

367 

*1=1; 

368 

) 

369 

s=Baum_String(k->r,s); 

370 

klammer_zu(&s,kl); 

371 

retum s; 

372 

} 

373 


374 

/*** Einsprung zum Differenzieren 

375 

*** (Term muß korrekt sein) ***/ 

376 


377 

void Difftchar ‘Angabe,char ‘Ergebnis) 

378 

{struct Knoten ‘Root,*d; 

379 


380 

Root=Baum_aufbauen(Angabe}; 

381 

Baum_zu_St ring(Root,Ergebnis); 

382 

puts(Ergebnis); 

383 

d=Differenziere(Root); 

384 

Baum_zu_String(d,Ergebnis); 

385 

Baum_abbauen(d); 

386 

Baum_abbauen(Root); 

387 

} 

388 


389 

/* nur ein kurzer Check */ 

390 

Term_korrekt(char *term) 

391 

{char c,*lastop=NULL,*p=term,*cp=term-l; 

392 

int kl= 0 ; 

393 


394 

while((c=*++cp)!= 0 ) if(!isspace(c)) { 

395 

if(strchrC()+-*/ A \c)) { 

396 

if(C==*(*) kl++; 

397 

eise if(c==’) 1 ) { 

398 

if(—kl <0 II lastop+l==cp II cp[-l]= 


= ' (') retum 0 ; 

399: 

} 

400: 

eise { 

401: 

if(lastop+l==cp II c!='-' && cp[-l]= 


= ' (') retum 0 ; 

402: 

lastop=cp; 

403: 

} 

404: 

} 

405: 

eise if(!isalnum(c) && c! = ’.’) retum 

0 ; 

*p++=C; 

406: 

407: 

} 

408: 

*P=0; 

409: 

retum kl== 0 ; 

410: 

> 

411: 


412: 

char Angabe[1024].Ergebnis[1024]; 

413: 


414: 

void main(int arge,char **argv) 

415: 

{if(argc==2 && Termjcorrekt(strcpy(Angab 
e.argvtl]))) { 

416: 

Diff(Angabe,Ergebnis); 

417: 

puts(Ergebnis); 

418: 

} 

419: 

} © 1993 M&T 

»Diff.c«: Das C-Progranim leitet einen 
mathematischen Ausdruck ab 


HHHHB 
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Mit dem Amiga 1200 
hat Commodore endlich 
den alten MC68000 durch 
einen schnelleren Prozessor 
ersetzt . Welche Neuerungen der 
20er bietet und was Programmie¬ 
rer alles aus ihm herausholen 
können, beschreibt dieser Artikel. 


von Georg Herbold, Alexander Kochann 
und Oliver Reiff 


M it den beiden brandneuen Amigas, 
dem Amiga 1200 und dem Amiga 
4000, geht die Ära des guten alten 
68000er auf dem Amiga zu Ende. Im neuen 
Amiga 1200 gibt nun ein mit 14 MHz getak¬ 
teter 68020er den Ton an. Der Amiga 4000 
hingegen besitzt keinen fest eingebauten Pro¬ 
zessor. Hier kann eine beliebige Prozessor¬ 
karte eingesetzt werden, die mindestens einen 
20er enthalten muß, wenn nicht gar einen 30- 
oder 40er. Ein alter 68000er bekäme mit den 
neuen Grafikauflösungen so seine Probleme. 

Wir wollen uns hier auf den MC68020 
beschränken, weil er nun den Grundbaustein 
bildet, auf dem künftig alle Programme auf¬ 
bauen können - und sollten welche die 
AA-Chips voraussetzen. Wenn Sie also die 
neuen AA-Chips voll ausnutzen wollen, kön¬ 
nen Sie mindestens einen MC68020 als Herz 
des Systems voraussetzen, dennoch sollten 
Sie zu Beginn eines Programms testen, ob 
nicht etwa ein 68000er oder 68010er einge¬ 
baut ist. Wie man das macht, zeigt Programm 
1, das zu »LessThan20« verzweigt, wenn 
eine ältere CPU installiert ist. 

Da die MC68000er Familie aufwärtskom¬ 
patibel ist, läuft die 20er Software auch auf 
einem höheren Prozessor. Die einzigen Ein¬ 
schränkungen stellen die Programme im 
Supervisor-Modus dar, in dem Anwenderpro¬ 
gramme aber sowieso nicht laufen sollten. 
Wer dennoch den Supervisor-Modus nutzen 
möchte, sollte sich entsprechende Literatur 
besorgen, da wir hier nicht darauf eingehen. 
Auf eine Inkompatibilität wollen wir Sie 


Beim Cache handelt es sich um einen 
extrem schnellen Speicher, in dem die letzten 
Befehle gespeichert und von dort wieder 
schnell abgerufen werden können. Dies 
macht sich besonders bei der Ausführung von 
Programmschleifen bemerkbar, die kleiner 
als 256 Byte sind, da diese komplett im 
Cache stehen und nicht mehr aus dem RAM 
geholt werden müssen. Dazu kommt noch 
das sog. Prefetch der Befehle. Dabei kann der 
20er schon den nächsten Befehl aus dem 
Speicher, bzw. Cache holen und decodieren, 
während er einen anderen bearbeitet. Das ein¬ 
zige, was der Programmierer beachten sollte, 
ist die alte Regel, keinen selbstmodifizieren¬ 
den Code zu schreiben, also nicht schreibend 
auf die unmittelbar abgearbeiteten oder fol¬ 
genden Befehle zuzugreifen. 

Der Rest geschieht ohne das Zutun des 
Programmierers, weshalb wir hier nicht näher 
darauf eingehen wollen. Die neuen Register, 
die bereits der MC68010 bereitsstellte, wol¬ 
len wir ebenfalls nur kurz vorstellen, da es 
sich um Register handelt, die nur vom Super- 


aller- 
dings noch 
aufmerksam ma¬ 
chen: Der Befehl 

»move sr,ea« ist nur beim 
MC68000 im User-Modus 
erlaubt. Statt dessen sollte besser die Funk¬ 
tion »GetCCO« aus der Exec-Library ver¬ 
wendet werden. Sie gibt die Bits des Condi- 
tioncode-Registers in dO zurück und das, 
egal, welche CPU vorhanden ist. 

Was ist beim MC68020 eigentlich anders 
als beim alten 68000er? Erst mal ist der 
68020er natürlich schneller als sein Vorfahr. 
Das liegt an der höheren Leistung, der höhe¬ 
ren Taktfrequenz und nicht zuletzt an dem 32 
Bit breiten internen Datenbus. Zusätzlich ist 
ein 256 Byte großer Cache-Speicher im Pro¬ 
zessor vorhanden. 


Cache mich: 68020 
mit Nachbrenner 
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>r-Modus aus angesprochen 
dürfen. Im einzelnen sind 
Register: 

- VBR - das Vector Base Register 

- SFC - Source Function Code 

- DFC - Destination Function Code 

Hierzu kamen für den MC68020 ebenfalls 
drei neue Register, die aber auch nur im 
Supervisor-Modus korrekt angesprochen 
werden dürfen. 

- A7" (MSP) - der Master StackPointer 

- CACR - das CAche Control Register 

- CAAR - das CAche Adress Register 

Viel wichtiger für Assembler-Programmie¬ 
rer ist die Tatsache, daß mit dem MC68020 
nun endlich auch Worte und Langworte an 
ungeraden Adressen liegen können und es 
deshalb weniger häugfig zum berühmten 
Guru 80000003 (ungerade Adresse) kommen 
kann. Ganz verbannt werden konnte dieser 
Guru jedoch noch nicht, da Befehle auch 
weiterhin unbedingt an geraden Speicherstel¬ 
len beginnen müssen. Auch Datenworte und - 
langworte sollten immer noch an geraden, 
bzw. durch vier teilbaren Adressen stehen, da 
sie dann auf einmal gelesen werden können. 
Im anderen Fall müssen sie sozusagen zer¬ 
stückelt gelesen oder geschrieben werden, 
was natürlich zusätzliche Zeit in Anspruch 
nimmt. Achten Sie deshalb vor allem bei 
zeitkritischen Routinen auf die Position ihrer 
Worte und Langworte. 

Doch auch auf diese Neuerung muß sich 
der Programmierer nicht umstellen. Viel 
interessanter für ihn sind die erweiterten 


move.l 

btst 

beq 

4.w,a6 

#1,296(a6) * AttnFlags testen 
LessThan20 

MC68020 

* 2Oer-Assemblierung 

* einschalten 

LessThan20 

MC68000 

* 20er aus ! 

Fehlerroutine 
bra Ende 

MC68020 

* 20er wieder ein ! 

Ende 

© 1993 M&T 

Listing 1: MC68020er-Test, hiermit te¬ 
sten Sie, was im Amiga steckt 



Amiga 1200: In seinem Innern schlägt 
statt des 68000 ein 68020-Prozessor 


Adressierungsarten. Einen Überblick der 
neuen Adressierungsarten finden Sie in Ta¬ 
belle 1. Diese Tabelle erweckt zuerst den 
Anschein, als gäbe es nur sechs neue Adres¬ 
sierungsarten. Dies ist jedoch nur bedingt 
richtig. Durch optionale Angabe von Parame¬ 
tern ergeben sich daraus knapp 40 Möglich¬ 
keiten, Befehle zu adressieren. 

Die ersten beiden Adressierungsarten stel¬ 
len keine prinzipielle Neuerung dar. Sie sind 
lediglich Erweiterungen altbekannter Arten. 
Neu ist nur, daß alle Offsets jetzt 32 Bit breit 
sind und eine Skalierung angegeben werden 
kann. Die erste Adressierungsart heißt zu gut 
deutsch: Adreßregister indirekt mit Index mit 
oder ohne 32-Bit-Adreßdistanz und Skalie¬ 
rung. 

Am besten vergleichen wir diese Art mit 
dem uns bekannten »d(An,Ri.s)«'. Der Befehl 
move.b #7 / 10(a4,d5.1) 

schreibt eine 7 an die Adresse, die sich aus 
10+a4+d5 ergibt. Nichts anderes bewirkt der 
Befehl 

move.b #7,(10,a4,d5.1*l) 

Es gibt jedoch zwei Unterschiede: 

Der Offset, der addiert wird, ist jetzt 32 
statt 8 Bit groß. Dazu kommt die Skalierung. 
Sie bewirkt eine Multiplikation des Register¬ 
inhalts mit 1, 2, 4 oder 8, so daß sich bei 
move.b #7,(444444,a4,d5.1*4) 
die effektive Adresse sich wie folgt errech¬ 
net: 

ea = 444444+a4+d5*4. 

Die zweite neue Adressierungsart erweitert 
quasi das bekannte dl6(pc,Ri.s) und ent¬ 
spricht der soeben erläuterten Art mit dem 
Unterschied, daß das erste Adreßregister 
durch den Programmcounter ersetzt wird. 
Auch hier bestehen die beiden Neuerungen 
darin, daß der Offset jetzt 32 Bit breit sein 
kann und daß der Registerinhalt mit 1, 2, 4 
oder 8 multipliziert werden kann. 


Das waren die sogenannten »einfachen 
Adressierungsarten«, die auch schon der 
MC68010 beherrschte. Mit dem 20er beginnt 
das Zeitalter der »komplexen Adressierungs¬ 
arten« auf dem Amiga. Doch keine Angst: 
Auch wenn sie zunächst unübersichtlich 
erscheinen, sind sie relativ leicht zu erlernen. 
Ihnen zugrunde liegt das Prinzip der doppelt 
indirekten Adressierung. Bei der direkten 
Adressierung wird eine Speicherstelle direkt 
angegeben, bei der indirekten Methode ein 
Adreßregister, das die Speicherstelle enthält, 
und bei der doppelt indirekten Art ein Regi¬ 
ster, das eine Speicherstelle enthält, die wie¬ 
derum auf die eigentliche Adresse zeigt. 
Alles klar? 

Mnemonik Art 

ldl 1 An,Ri.s*scll ARI. [+Offset32], ^Skalierung] 

(label,pc,Ri.s*scl) pc-relatic (+Offset32j [^Skalierung] 

([d 1 ,An],Ri^*scL,d2) doppelt indirekt. Post-Index 

(|dl,pc],Ri.s*sci,d2) doppelt indirekt, Post-index. pc-relativ 

((dlMRi^*sclJ42) doppelt indirekt, Pre-Index 

(|dl,pc,RLs*sd],d2| doppelt indirekt. Pre-Index. pc-relativ 

Erklärungen zu Mnemonik: 
dl / <12 32-Bit-Offset 
An beliebiges Adressregister 

Ri.s beliebigers Register mit Größenangabe (word oder long) 
sei Skalierung (multipliziert Registerinhalt mit 1.2,4 oder 8) 
pc Programm Counter 

ARI AdreßRegistcr Indirekt ( entspricht z.B. (a0)) 

Angaben bei Art in eckigen Klammem sind optional, können 
also weggelassen werden. Bei den letzten vier Adressierungsar¬ 
ten unter Mnemonik sind praktisch alle Bestandteile optional 
»((!)« ist erlaubt 

Tabelle 1: Die neuen Adressierungsar¬ 
ten in Verbindung mit dem 68020 

Dazu zunächst ein ganz einfaches Beispiel, 
das bekanntlich mehr als 1000 Worte sagt: 
Der Befehl 
move.b #7,([aO]) 
faßt quasi die Befehle 
move.l (aO),aO 
und 

move.b #7,(aO) 

zusammen, ohne jedoch aO zu verändern! 

Im nächsten Beispiel wollen wir es einmal 
so richtig kompliziert machen: statt des 
Befehls 

move.b #7,([10,aO],d5.w*8,20) 
könnte man auch 
move.l 10(a0),a0' 
mulu #8,d5 

move.b #7,20(a0,d5.1) 

schreiben, wobei allerdings aO und d5 verän¬ 
dert würden. 
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Das Prinzip der Adressierung ist eigentlich 
ganz einfach: In eckigen Klammem steht die 
Speicherstelle, die doppelt indirekt adressiert 
wird. Danach stehende Angaben werden auch 
erst danach addiert. 

Wie man in der Tabelle ebenfalls erkennen 
kann, darf anstelle des ersten Adreßregisters 
auch wieder der Programmzähler verwendet 
werden, so daß diese Adressierungsarten 
auch pc-relativ verwendet werden können. 
Ein Beispiel hierfür wäre: 
move.l dO,([label(pc)],10) 

Doch nicht nur neue Adressierungsarten 
wurden implementiert. Auch neue Befehle 
stehen zur Verfügung. Diese haben wir eben¬ 
falls für Sie im Überblick zusammengefaßt 
(siehe Tabelle 2). Da haben wir als erstes die 
Bit-Feld-Befehle. Wie der Name sagt, lassen 
sich damit nicht nur einzelne, sondern meh¬ 
rere Bits gleichzeitig beeinflussen. Dazu muß 
neben der Adresse auch das erste Bit und die 
Größe des Bit-Felds angegeben werden 

Statt langen Worten: 
Bit-Felder 

Besonders einfach wird die Bit-Feld-Pro- 
grammierung dadurch, daß man als Program¬ 
mierer weder an Byte-, Word- noch Lang¬ 
wortgrenzen gebunden ist. 

Der folgende kurze Befehl 
bfclr dO,{7:4} 

löscht von Bit 7 an 4 Bit und funktioniert wie 
»bclr«, d.h. die angegebenen Bits werden 
gelöscht und die Flags werden gesetzt. Da die 
Befehle »bfchg«, »bfclr«, »bfset« und »bftst« 
genauso arbeiten wie ihre Ein-Bit-Kollegen, 
bedürfen sie keiner längeren Erklärung. Inter¬ 
essanter sind wohl die Befehle ’bfexts', bzw. 
»bfextu«. Sie übertragen ein Bit-Feld in ein 
Datenregister, das bei »bfextu« vorher 
gelöscht und bei »bfexts« wie bei »ext.x« 
vorzeichenrichtig erweitert wird. Umgekehrt 
schreibt »bfins« ein Bit-Feld aus einem 
Datenregister zurück in den Speicher. Als 
letzter Bit-Feld-Befehl bleibt »bfffo«, was 



mc68020 

* 20er einschalten 


lea 

bcd,aO 


move.l 

aO,al 


lea 

bcdende,a2 


move.l 

a2,a3 


moveq 

#3,d0 


move.l 

d0,dl 

loop 

pack 

-(aO),-(a2),#-$3030 



* umwandeln 


dbra 

dO,loop 

loop2 

unpk 

-(a3),-(al),#$3131 


* umwandeln und 1 mehr addieren 


dbra 

dl,loop2 


rts 


bcd 

dc.l 

0 

bcdende 



text 

dc.b 

"12345678" 


© 

1993 M&T 

Listing 2 : Demo zu den neuen Befehlen 

des 68ü20ers »pack« und »unpk« 


die Abkürzung für »bit field - find first one« 
bedeutet. Er sucht die erste »1« in einem Bit- 
Feld und schreibt die Nummer dieses Bits ins 
Register dn. Findet er in dem angegebenen 
Bit-Feld keine »1«, wird die Länge des Bit- 
Felds plus eins zurückgegeben. Außerdem 
wird das Z-Flag entsprechend gesetzt. 

Die nächste Gruppe bilden die Divisions- 
bzw. Multiplikationsbefehle. Der Befehl 
»divs.l« teilt jeweils zwei 32-Bit-Zahlen und 
speichert den Quotienten im 32-Bit-Zielregi- 
ster ab. Ähnlich arbeitet »muls.l«, der zwei 
32-Bit-Zahlen miteinander zu einer 32-Bit- 
Zahl multiplizieren. Selbstverständlich gilt 
gleiches für die vorzeichenlose Division, 
bzw. Multiplikation, also »divu« und 
»mulu«. Nichts Neues, werden Sie denken, 
was im Prinzip richtig ist. Aber diese Befehle 
wurden alle auf 32 Bit erweitert, wodurch 
sich z.T. ein anderer Syntax ergibt, wie die 
folgende Gruppe der Divisions- und Multipli¬ 
kations-Befehle zeigt: 

Bei »divs.l« können auch zwei Register als 
Ziel angegeben werden, beispielsweise divi¬ 
diert »divs.l #7,dl:d0« das Register dO durch 
7. Dl wird dabei nicht beachtet. Erst nach der 
Division enthält das Datenregister dl den 32 
Bit großen Rest und dO den 32 Bit großen 
Quotienten der Division. 

Doch es gibt noch eine weitere Variante: 
Mit »divsl.l« kann sogar eine 64-Bit-Zahl 
dividiert werden. So würde »divsl.l 
#7,dl:d0« eine 64-Bit-Zahl, deren oberes 
Langwort in dl und deren untereres Lang¬ 
wort in dO untergebracht ist, durch 7 teilen. 
Die Rückgaberegister verhalten sich wie bei 
»divs.l«. Auch bei der Multiplikation zweier 
32-Bit-Zahlen werden meistens 64-Bit-Zah- 
len entstehen, die dann ebenfalls in zwei 
Datenregistem untergebracht werden müssen. 
Dazu gibt es den Befehl »muls.l«, der das 
obere Lang wort in »dr« und das untere Lang¬ 
wort in »dq« ablegt. 

Die Anweisungen »pack« und »unpk« hel¬ 
fen dem Programmierer beim Umgang mit 
BCD-Zahlen. »Pack« wandelt dabei einen 
Zahlenstring in eine BCD-Zahl um. Dazu 
kann außerdem eine Konstante angegeben 
werden, die auf den String addiert wird. Es 
empfiehlt sich #-$3030. Bei dem entgegenge¬ 
setzten Befehl »unpk« sollten wieder #$3030 
addiert werden. Am besten betrachten Sie 
dazu das Programm 2. Es enthält nach einem 
Durchlauf in »text« den String »23456789« 
und in »bcd« die Zeichenfolge »$12345678«. 

Das waren die wesentlichen Befehlsgrup¬ 
pen. Im folgenden Abschnitt wollen wir auf 
einige einzelne Befehle eingehen. 

Da wäre beispielsweise als erstes der 
Befehl »cmp2.x grenzen,ea«. Mit ihm kann 
der Wert in ea gleichzeitig gegen zwei Gren¬ 
zen aus einer Tabelle getestet werden. Dazu 
folgendes kurzes Beispiel, das testet, ob dO 
zwischen 10 und 20 liegt und dementspre¬ 
chend verzweigt: 
cmp2.1 grenzen, dO 
bcs außerhalb 
bcc innerhalb grenzen: 
dc.l 10,20 


BFCHG <ea>{bo.:bfl.} 
BFCLR <ea>{bo:bf1} 
BFEXTS<ea>{bo:bfl),dn 
BFEXTlkea>{ bo: bfl},dn 
BFFFO <ea>{bo:bfl},dn 
BFINS dn,<ea>{bo:bfl} 
BFSET <ea>{bo:bfl} 

BFTST <ea>{bo:bfl) 

Bitfeld invertierten 

Bitfeld löschen 

Bitfeld vorzeichenrichtig übertragen 

Bitfeld vorzeichenlos übertragen 

Finde erste 1 im Bitfeld 

Bitfeld aus dn in Speicher schreiben 

Bitfeld setzen 

Bitfeld testen 

DIVS.L<ea>,dn 

DIYUL<ea>,dn 

MULSl<ea>,dn 

MULUl<ea>,dn 

Division mit V orzeichen (32 Bit+32 Bit) 
vorzeichenlose Division (32 Bit+32 Bit) 
Multiplikation mit Vorz. (32 Bit»32 Bit) 
Multiplikation ohne Vorz. (32 Bit»32 Bit) 

DIVS.L<ea>,dr:dq 
DIVSL.L <ea>,dr:dq 
DrVU.L<ea>,dr:dq 
DIVUL.L <ea>,dr:dq 
MULS.L<ea>,dr:dq 
MULU.L<ea>,dr:dq 

Division mit Vorzeichen (64 Bit+32 Bit) 
Division mit Vorzeichen (32 Bit+32 Bit) 
vorzeichenlose Division (64 Bit+32 Bit) 
vorzeichenlose Division (32 Bit+32 Bit) 
Multiplikation mit Vorz. (32 Bit*32 Bit) 
Multiplikation ohne Vorz. <32 Bit*32 Bit) 

PACK-(Am),-(An),#x 
PACKDmJ)n,#x " 
UNPK-(Am),-(An),#x 
UNPKDm,Dn,#x " 

bilde gepackte Dezimalzahl und addiere #x 

bilde ungepackte Dezimalzahl und addiere #x 

CHK2.xgrenzen.ea 

CMP2.xgrenzen,ea 

wie chk, nur mit zwei Grenzen 
wie cmp, nur mit zwei Grenzen 

EXTB.Ldn 

RTD#x 

erweitert dn.b direkt vorzeichenrichtig 
auf dn.1 

wie rts, addiert aber v orher #x auf den Stapel 

MOVEccr,ea 

schreibe Conditioncoderegister nach ea 

BKPT#x 

Breakpoint Nummer #x setzen 

CALLM#x,ea 

CAS.X Dc,Du,ea 
CAS2.xDcI:Dc2,Dul: 
Du2,(Rn):(Rm) 

Aufruf eines ModuLs mit Deskriptor 

Wenn Dc=ea, dann Du->ea. sonst ea->Dc 

wie CAS nur mit zwei Vergleichswerten ??? 

MOVEC.x Rc,Rn 

M0VEC.X Rn.Rc 

MOVES.x Rn,ea 

MOVES.x ea,Rn 

I.ese Supervisor-Register 

Lade Supervisor-Register 

Lade alternativen Adreßbereich 

Lese alternativ en Adreßbereich 

RTMRn 

TRAPccea 

Rückkehr aus einem Modul 
und Löschen des Deskriptors 
bedingter Sprung in eine Exception 
erstes Bit des Feldes (0-31 oder Datenregister 
Größe des Bitfelds in Bits (1-32) 


Tabelle 2: Die zusätzlichen Befehle des 
68020er Prozessors 


Neu ist auch der »extb.l«-Befehl, der das 
Lowbyte eines Registers vorzeichenrichtig 
auf das ganze Register erweitert. Er faßt also 
die Anweisungen »ext.w« und »ext.l« in 
einem Schritt zusammen. Ebenfalls eine 
Kurzfassung zweier Befehle bietet die 
Anweisung »rtd #x«, die »add.l #x,sp« und 
'rts' in sich vereint. Diese Anweisung ist vor 
allem für die Programmierung von Unterrou¬ 
tinen interessant, die die Parameter auf dem 
Stack ablegen, wie dies bei Hochsprachen 
allgemein üblich ist. 

Die anderen Befehle, die am Ende der 
Tabelle stehen, sollten Sie besser nicht ver¬ 
wenden, da sie teils privilegiert, teils nicht 
aufwärtskompatibel sind. Aber auch die 
erlaubten Befehle, die neuen Adressierungs¬ 
arten und der schnellere Prozessor generell 
sollten Sie bereits zu neuen Höchstleistungen 
animieren. ub 

Literaturhinweis: 

Werner Hilf. »Mikroprozessoren für 32-Bit-Systeme«. Band 1. 
M&T-Verlag 
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Universeller Kreuzreferenzgenerator 

Leichter durch den Dschungel 


Wenn ein Programm über eine lange Zeit reift, geraten häufig die gut 
funktionierenden Teile aus dem Blickfeld. Spätestens bei den ab¬ 
schließenden Arbeiten wünscht man sich ein Tool, das bei der Analyse 
des Quelltextes hilft, um den Überblick zurückzugewinnen. Der hier 
vorge stellte und für beliebige Sprachen ersetzbare Kreuzreferenzgene¬ 
rator ist hervorragend geeignet, Quelltextdschungel zu durchdringen. 


7 #define Dim 4 // Dimension der Matrix 

8 

9 dass Matrix // Klassendeklaration 
10 { 

11 int matritze[Dim][Dim]; // durch Klasse 
gekapselt 

12 . 

13 public: // folgende. Elemente von 

aussen zugreifbar 

14 

15 MatrixO; // Konstruktor initialisiert 

die Klasse 

16 

17 Matrix operator + (Matrix); 

// Ueberladen von + 

18 void Ausgabe (); 

19 }; 

20 

21 Matrix::MatrixO // Klasse init. 

22 { 

23 int y; 

24 

25 for (int x = 0; x < Dim; x++) // Zeilen 

26 for (y = 0; y < Dim; y++) // Spalten 

27 matritze[x] [y] = Dim; // Alle 
Elemente sind DIM 

28 } 

29 

30 Matrix Matrix::operator + (Matrix ma2) 

31 { 

32 Matrix ergebnis; 

33 int y; 

34 

35 for (int x = 0; x < Dim; x++) 

36 for (y = 0; y < Dim; y++) 

37 ergebnis.matritze[x][y] 

38 = matritze[x][y] + ma2.matritze[x][y]; 

39 retum ergebnis; 

40 } 

41 

42 void Matrix::Ausgabe () 

43 { 

44 cout « "\n*; 

45 for (int x = 0; x < Dim; x++) 

46 { for (int y = 0; y < Dim; y++) 

47 cout « matritze[x][y] « ' ’; 

48 cout « "\n"; 

49 } 

50 cout « *\n"; 

51 } 

52 

53 int main() 

54 {. 

Kreuzreferenzen: 

Ausgabe 18 42 58 

cout 44 47 48 50 

Dim 7 11 25 26 27 35 36 45 46 

ergebnis 32 37 39 

h 4 5 

iostream 4 

maO 55 57 

mal 55 57 


ma2 

30 

38 

55 

57 

58 




main 

53 








matritze 

11 

27 

37 

38 

47 




Matrix 

9 

15 

17 

21 

30 

32 

42 

55 

stdlib 

5x 

25 

27 

35 

37 

38 

45 

47 

y 

23 

26 

27 

33 

36 

37 

38 

46 47 


Listing 1: Ausschnitt aus einer Refe¬ 
renzliste, die mit dem Kreuzreferenzge¬ 
nerator erstellt wurde. Der Ausschnitt 
zeigt, daß der einfache Ansatz nicht zwi¬ 
schen globalen und lokalen Variablen 
unterscheidet. So kommen x und y in 
mehreren Funktionen vor. Wie wäre es, 
wenn Sie das Programm so ausbauten, 
daß es Lokalitäten berücksichtigt? 


von Edgar Meyzis 

B ei der Bereinigung von Quelltexten 
stellen sich Fragen wie die nach 
»unvollendeten Baustellen«, Vereinba¬ 
rungsorten von Konstanten und Variablen 
oder der Vergabe aussagekräftiger Namen. 
Diese und ähnliche Fragestellungen lassen 
sich durchaus schrittweise mit einem Editor 
bewältigen. Leichter geht es jedoch mit 
einem Kreuzreferenzgenerator (KRG). 

Vogelperspektive 

Was leistet er? - Der zu analysierende 
Quelltext wird mit Zeilennummem versehen 
und in eine Datei geschrieben. Es folgt eine 
alphabetisch geordnete, formatierte Liste 
sämtlicher Namen (Bezeichner), die im Pro¬ 
grammtext verwendet wurden. Für jeden 
Namen ist die Nummer der Zeile vermerkt, in 
der er vorkommt, über Namen und Zeilen¬ 
nummern (cross reference) fällt die Orientie¬ 
rung im Quelltext leicht. So erzeugte Kreuz¬ 
referenzen (KR) können mit Texteditoren 
bearbeitet werden. Listing 1 zeigt aus¬ 
schnittsweise KR für ein Programm in C++. 

Ein KRG muß den Wortschatz der Pro¬ 
grammiersprache des zu analysierenden 
Quelltextes kennen, um reservierte Wörter 
(Schlüsselwörter) zu filtern. Unser KRG ist 
universell ausgelegt und lernfähig. Über 
einfache Textdateien können ihm die reser¬ 
vierten Wörter der jeweiligen Sprache (z.B. 
dass oder WHILE) vorgegeben werden. An¬ 
hand der Endung eines Dateinamens erkennt 
er die zu berücksichtigende Sprache. Der 
KRG kann in der derzeitigen Version nicht 
zwischen Cluster, Modula-2 und Oberon dif¬ 
ferenzieren, da die drei Sprachen mit densel¬ 
ben »Suffixes« arbeiten. So bleibt Raum für 
Verbesserungen durch unsere Leser. 

Selbst wenn Sie keinen KRG benötigen, 
bieten unsere Listings anschauliche Bei¬ 
spiele, Texte zu scannen und zu parsen sowie 
binäre Bäume zu errichten und darin herum¬ 
zuturnen. Vielleicht benötigen Sie auch nur 
ein Tool, um die Zeilen eines Programms zu 
numerieren. Dann ignorieren Sie einfach die 
ausgegebene KR. 


Spezifikation und 
Entwurf 

Das Programm »Kreuzref.mod« (Listing 5) 
ist in Modula-2 (M2AMIGA 4.1) geschrie¬ 
ben und so kommentiert, daß es leicht in eine 
andere Sprache umgesetzt werden kann. Es 
wurde für das Betriebssystem (OS) der Ver¬ 
sion 1.3 ausgelegt. Bei strikter Anlehnung an 
OS 2.0 wären einige Funktionen einfacher zu 
implementieren gewesen. Auch hätte es sich 
angeboten, den ASL-Requester einzusetzen. 



KreuzRef 

Argument 

auswerten 

Existenz 

Datei prüfen 

Name der 
Quelltextdatei 

Quelltextdatei u. 
reserv. Wörter 

Quelltext 

Suffix 

auswerten 

reservierte 

Wörter 





Kreuzreferenz 

erzeugen 


Kreuzreferenz xrf-Datei 


Ende 


Bild 1: Datenfluß in unserem Pro¬ 
gramm Kreuzreferenz 

Manchen Lesern wird das Thema schon 
von unserem Kurs Mit System Entwickeln 
[1] her bekannt sein. Er führte zum sprachun- 
abhängigen Entwurf eines KRG. Dabei erga¬ 
ben sich u.a. ein Diagramm für den Informa¬ 
tionsfluß im KRG ähnlich Abb. 1 und die 
»Spielregeln« gern. Listing 2, um Quelltexte 
Programmiersprachen zuzuordnen. Wichtige 
Ergebnisse des Entwurfs (AMIGA 9/91, S. 
166 ff) sollen ausschnittsweise und stark ver¬ 
kürzt wiederholt werden, damit Sie das Pro¬ 
gramm leichter nachvollziehen können. 
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Bäume pflanzen 

Der KRG setzt dynamische Datenstruktu¬ 
ren ein, um Quelltexte mit beliebig vielen 
Namen (innerhalb der Grenzen des verfügba¬ 
ren Arbeitsspeichers) analysieren zu können. 
Die Adressen der Namen und der reservier¬ 
ten Wörter werden getrennt in zwei sortier¬ 
ten, binären Bäumen abgelegt. Die Bäume 
lassen sich sehr effizient bearbeiten, wenn die 
einzelnen Knoten systematisch aufeinander 
verweisen. Die Verwaltung von Namen und 
reservierten Wörtern in einheitlich organi¬ 
sierten Bäumen bietet den Vorteil, mit einem 
Satz an Algorithmen für beide Bäume aus¬ 
zukommen. 


CONST SprachlD = "MOD_DEF_CPP_HPP_BAS_PAS_C_H"; 

(* A . .*) 

(*0 4 8 12 16 20 24 26 *) 

CASE id OF 

0..4 : wortText: := *S:Modula.Words # ; 

{* zgl. Cluster*) 

spräche := Modula; (* und Oberon *) 

I 8 ..12: wortText := "StCPP.Words"; 
spräche := Cpp; 

i 16 : wortText := "SrBasic.Words"; 

spräche := Basic; 

I 20 : wortText := "S:Pascal.Words"; 

spräche := Pascal; 

I 24..26 : wortText := "S:C.Words"; 
spräche := C; 

END; © 1993 M&T 

Listing 2: Aus dem Suffix wird auf die 
Sprache des Quelltextes geschlossen. 
Modula-2 steht zugleich für Cluster und 
Oberon. Mit einem zusätzlichen Argu¬ 
ment bei Aufruf des Programms ließe 
sich differenzierter Vorgehen. 


Für die Erzeugung von KR reicht das ein¬ 
fache Verfahren der Binärsuche [2] aus. Dazu 
sind die Knoten der Bäume entsprechend 
Abb. 2 anzulegen und z.B. gern. Listing 3 zu 
implementieren. Ein kleiner Unterschied in 
der Verwaltung der beiden Informationsarten 
(Name oder reserviertes Wort) besteht schon. 
Für reservierte Wörter ist »numList« (Anfang 
der Liste mit den Zeilennummem) »NIL«, da 
sie nicht in die KR eingehen. Im Baum der 
Namen hingegen verweist »numList«' auf 
eine einfach verkettete Liste, deren Elemente 
eine Zeilennummer und einen Zeiger auf das 
nächste Element enthalten (vgl. Abb. 2). So 
ist sichergestellt, daß unser KRG mit beliebig 
häufigen Vorkommen eines Namens umge¬ 
hen kann (Merkmal dynamischer Program¬ 
mierung). 

Links vor rechts 

Die Verhältnisse im Baum selbst gehen aus 
Abb. 3 hervor. Es wird veranschaulicht, wie 
Knoten mit reservierten Wörtern oder Namen 
in Bäume einzufügen sind. Der Suchvorgang 
innerhalb eines Baums ist in Abb. 4 als 
Struktogramni dargestellt und in Listing 4 
als Prozedur »NamenSuchen« implementiert. 

Wenden wir doch einmal das Strukto- 
gramm auf den Baum in Abb. 3 an und bege¬ 
ben uns auf die Suche nach dem reservierten 
Wort BYTE: 



Bild 2: Die Knoten der Binärbäume 
enthalten insgesamt vier Adreßinfor- 
mationen. Die Einträge li(nks) und 
re(chts) ermöglichen es, einen Baum 
aufzuspannen. wortAdr verweist auf 
ein reserviertes Wort oder auf einen 
Namen. Die Zeilennummern werden 
in einer einfach verketteten Liste ab 
num List festgehalten 

Step 1: Der Wurzelknoten verweist auf 
Knoten 1 mit der Adresse von »ABS«. Der 
Vergleich von ABS mit BYTE ergibt, daß 
nach rechts weiter zu verzweigen ist: q := 
p A .re;). 

Step 2: BYTE < DEC somit: q := p A .li; 

Step 3: BYTE > BY somit: q := p A .re; 

Step 4: BYTE = BYTE somit: RETURN p; 

Das Beispiel zeigt, wie einfach es ist, 

Informationen im Baum schnell zu finden. 

Rekursiv von Ast zu 
Ast 

Die Routine NamenSuchen (Listing 4) 
wurde nicht rekursiv implementiert, um den 
Einstieg in die Baumtechnik zu erleichtern. 
In der Prozedur WeiterlmBaum (Listing 4) 
finden Sie ein rekursives Verfahren, um 


sich mit wenigen Programmzeilen von Ast zu 
Ast der beiden Bäume zu schwingen und die 
enthaltenen Informationen auszugeben. Es 
sollte gleichfalls leicht nachzuvollziehen 
sein. Listing 4 enthält die vollständigen 
Baumalgorithmen. 


TYPE 

ZeichenPtr = POINTER TO CHAR; 

ListPtr = POINTER TO Element; 

Element = RECORD 

(* Knoten einer einfach verketteten Liste *) 
zeilNum : INTEGER; 

(* Zeilennummer eines Namens *) 
next : ListPtr; (* naechstes Element*) 

END; 

BaumPtr = POINTER TO Knoten; 

Knoten = RECORD 

(* Blaetter der beiden Binaerbaeume *) 
wortAdr : ZeichenPtr; 

(* Name oder reserv. Wort *) 
numList : ListPtr; 

(* auf Liste mit Zeilennr *) 
li, re : BaumPtr; (* Baum verzweigt *) 

END; © 1993 M&T 

Listing 3: Zwei Datenstrukturen for¬ 
men die binären Bäume. Die einfach 
verkettete Liste setzt sich aus dem Typ 
Element zusammen, um Nummern der 
Zeilen aufzunehmen, in denen die 
Namen des analysierten Programms 
Vorkommen. 


Da die Speicheranforderungen über den 
»Heap« erfolgen, ist es nicht explizit erfor¬ 
derlich, die angeforderten Bereiche freizuge¬ 
ben. Bei Programmende übernimmt das 
Laufzeitsystem diese Aufgabe. Würde das 
Programm beim Aufruf mehr als eine Datei 
als Argument akzeptieren, dann wäre zumin¬ 
dest der Namensbaum abzubauen. 

(bitt lesen Sie weiter auf Seite 100( 


NamenSuchen 


Baum durchqueren bis Na¬ 
men gefunden o. Knoten er¬ 
reicht, der auf Namen wei- 

sen müßte 




Vergleiche 




gefunden / 


nein 

\/ja 


kleiner ^ 
ja nein 
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Vergleiche 


Zwei Strings Zeichen für 
Zeichen vergleichen, so¬ 
lange die Zeichen gleich 
sind o. das Ende einer 
Kete erreicht ist 


Zeichen vergleichen 


Ergebnis festhalten 


Bild 4: Die Suche nach einem Namen in einem binären Baum in Form eines 
Struktogramms dargestellt 
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165 

* Hier sollten Sie alie auftretenden Fehler 

166 

* abfangen und dem Benutzer mit Hilfe von 

167 

* Requestern darauf hinweisen. Wir haben 

168 

* darauf verzichtet, 

um das Programm nicht 

169 

* unnötig zu verlängern. 


170 




171 

No_OS2 moveq 

#-10,d7 


172 

bra.s 

Err_0S2 


173 

No_Screen moveq 

#-10,d7 


174 

bra.s 

Err_Screen 


175 

No Window moveq 

I-I0,d7 


176 

bra.s 

Err Window 


177 

No_Menu moveq 

#-10.d7 


178 

bra.s 

Errjfenu 


179 

No_Layout moveq 

«-10,d7 


180 




181 

182 

GetTextLenght 



183 

movem.l 

dl/a0-a2/a6 

, - (sp) 

184 

move.1 

a0,a2 


185 

move.1 

Screen,al 


186 

lea 

84 (all,al 

* RastPort 

137 

moveq 

#-1,dO 


188 

.loop addq.l 

#l,d0 


189 

tst.b 

(a2} + 


190 

bne.s 

.loop 


191 

move.1 

GfxBase,a6 


192 

jsr 

-54(a6) 

TextLenght 

193 

movem.l 

(sp)+,dl/a0-a2/a6 

194 

rts 







196 

PrintText movem.l 

d0-dl/a0-a2/a6,-(sp) 

197 

move.l 

a0,a2 


198 

move.l 

RastPort,al 

199 

moveq 

#-l,d0 


200 

.loop addq.l 

#l,d0 


201 

tst.b 

<a2) + 


202 

bne.s 

.loop 


203 

move . 1 

GfxBase,a6 


204 

jsr 

-60(a6) 

Text 

205 

movem.l 

(sp)4,dO-dl/aO-a2/a6 

206 

207 

208 

rts 



SetPen movem.l 

d0-dl/a0-al/a6,-(sp) 

209 

move.w 

d2,d0 


210 

move.l 

RastPort,al 

211 

move.l 

GfxBase,a6 


212 

jsr 

-342U6) 

SetAPen 

213 

movem.l 

(sp)+,d0-dl/a0-al/a6 

214 

rts 



215 

Move movem.l 

d0-dl/a0-al/a6,-{sp) 

216 

move.l 

RastPort.al 

217 

move.1 

GfxBase,a6 


218 

jsr 

-240la6) 

Move 

219 

movem.l 

Isp)+,d0-dl/a0-al/a6 

220 

rts 



221 

opt 

P- 


222 

IntBase 

dc.l 

0 

223 

GfxBase 

dc.l 

0 

224 

GadBase 

dc.l 

0 

225 

RastPort 

dc.l 

0 

226 

MessagePort 

dc.l 

0 

227 

Drawlnfo 

dc.l 

0 

228 

VisualInfo 

dc.l 

0 

229 

Font 

dc.l 

0 

230 

Menu 

dc.l 

0 

231 

Window 

dc.l 

0 

232 

YSize 

dc.w 

0 

233 

BaseLine 

dc.w 

0 

234 

WindowData 

dc.w 

0,0,0,0,1 

235 


dc.l 

$300,$2100f,0,0,WindowName 

236 

Screen 

dc.l 

0,0 

237 


dc.w 

0,0,-1,-1,15 

238 

WindowTags 

dc.l 

TAG_USER+147,1 

239 

WA^InnerWidth 

dc.l 

TAGJJSER+118,0 

240 

WA_InnerHeight 

dc.l 

TAGJJSER+119,0 

241 


dc.l 

0 

242 

NewMenu 

dc.b 

1,0 

243 


dc.l 

MenuTitle_l,0 

244 


dc.w 

0 

245 


dc.l 

0,0 

246 


dc.b 

2,0 

247 


dc.l 

MenuPoint_l,T_Key 

248 


dc.w 

$109 

249 


dc.i 

0,0 

250 


dc.b 

2,0 

251 


dc.l 

-1,0 

252 


dc.w 

0 

253 


dc.l 

0,0 

254 


dc.b 

2,0 

255 


dc.l 

MenuPoint_3,V_Key 

256 


dc.w 

0 

25'’ 


dc.l 

0,0 

258 


dc.l 

0 

259 

NewMenuTags 

dc.l 

TAG_USER+$80043,1 

260 


dc.l 

0 

261 

VersionString 

dc.b 

’SVER: WB-Beispielprogramm (11.11.92)',0 

262 

IntName 

dc.b 

'intuition.library',0 

263 

GfxName 

dc.b 

'graphics.1ibrary *,0 

264 

GadName 

dc.b 

'gadtools.library',0 

265 

PupScreen 

dc.b 

'Workbench',0 

266 

WindowName 

dc.b 

'Testfenster',0 

267 

MenuTitle_l 

dc.b 

'Projekt',0 

268 MenuPoint_l 

dc.b 

'Test',0 

269 

: MenuPoint_3 

dc.b 

'Verlassen',0 

270 

: Text_l 

dc.b 

'Nicht vergessen:’,0 

271 

: Text_2 

dc.b 

'Die WB ist unberechenbar...',0 

272: T Key 

dc.b 

'T',0 

273 

: V_Xey 

dc.b 

’V\0 

274 

END 

© 1993 M& 

WB-Beispielprogranini: Das Programm zeigt, was unter OS 
2.0 zu beachten ist (Fortsetzung von Seite 9) 



MaxonC* 

Das erste vollständige C/C* + -Entwick- 
lungssystem für den AMIGA bietet zwei 
Compiler in einem: ANSI C und - für die 
zukunftsweisende objektorientierte Pro¬ 
grammierung - C ++ nach dem AT&T 2.0- 
Standard. Das Entwicklungssystem ent¬ 
hält einen sehr flexiblen Editor, den 
schnellen C/C ++ -Compiler, einen Ober¬ 
flächengenerator und ein Online- 
Hilfesystem. Die Developer-Version ent¬ 
hält zusätzlich einen optimierenden Ma¬ 
kro-Assembler (68000/20/30) und ei¬ 
nen leistungsfähigen Source-Level-De- 
bugger. DM 398,-/ 598,- (Developer) 

KickPascal 

Das KICK-PASCAL-Entwicklungssys- 
tem besteht aus einem komfortablen 
Editor, schnellem Single-Pass-Compi- 
lerund integriertem Linker. DerSprach- 
umfang wurde um fast 100 Befehle ge¬ 
genüber dem Standard erweitert und 
enthält viele nützliche Funktionen. Mäch¬ 
tige Units nehmen dem Programmierer 
manches Problem ab. KICK-PASCAL 
ist für Einsteiger und Umsteiger von 
anderen Sprachen oder Compilern (Tur- 
bo-Pascal) sowie Programmierprofis 
bestens geeignet. DM 249,- 

MaxonASM 

Das professionelle Assembler-Entwick¬ 
lungspaket bietet eine integrierte Ar¬ 
beitsumgebung, bestehend aus schnel¬ 
lem komfortablem Editor, makrofähi¬ 
gem hochoptimierendem Assembler, 
umfangreichem Monitor/Disassembler, 
leistungsfähigem symbolischem De¬ 
bugger und interaktivem symbolischem 
Reassembler. Ein Komplettsystem, das 
allen Ansprüchen von Einsteigern und 
Profis gerecht wird. DM 149,- 

Der AMIGA-Entwicklungs- 
minister empfiehlt: Fordern 
Sie unseren Katalog an. 

MAXON Computer GmbH • Industriestraße 26 • W-6236 Eschborn 
Tel.: 061 96 /481811 • Fax: 061 96/41 885 
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Bild 3: Binärbaum für reservierte 
Wörter mit neun Knoten. Vier Kno¬ 
ten verweisen auf reservierte Wörter, 
die zusammenhängend im Speicher 
abgelegt sind. Ein rekursiver Algo¬ 
rithmus zum Durchsuchen des Baums 
muß die Knoten in der Reihenfolge 
von 0 bis 8 besuchen. Erkennen Sie 
die englischen Verhältnisse im Baum? 
Es gilt links vor rechts. 


Das Programm gliedert sich insgesamt in 
fünf Module, die über schmale Schnittstellen 
gekoppelt sind. Das Hauptmodul Kreuz- 
Ref.mod arbeitet mit den Modulen ßinär- 
Baum (allgemeine Routinen für die Arbeit 
mit den Bäumen), ResWortBaum (Baum 
mit reservierten Wörtern aufspannen), Refe- 
renzBaum (Namensbaum bilden, KR erzeu¬ 
gen) und DateiHandling. Listing 5 enthält 
die Schnittsteilendefinitionen der Module, 
um Sie mit der Programmstruktur vertraut zu 
machen. Die vollständigen Listings finden 
Sie auf der zum Heft gehörenden PD-Dis- 
kette im Verzeichnis »KreuzReferenz« 
(siehe auch Seite 114). 

Wann lichten Sie 
Ihre Urwälder? 

Zur Funktion des Programms ist ab¬ 
schließend noch anzumerken, daß es bei 
erweiterter Selektion (SHIFT Klick Datei, 
SHIFT Klick KreuzRef) von der Workbench 
arbeitet, ohne jedoch ein Icon für die 
erzeugte Referenz anzulegen. Die Dateien 
mit den reservierten Wörtern müssen sich 
im Verzeichnis S: (vgl. Listing 2) befinden. 
Für Basic, C, C++ und Modula-2 sind ent¬ 
sprechende Dateien (als Muster) mit einem 
Grundstock an reservierten Wörtern auf der 
PD-Diskette beigefügt. Die Reihenfolge in 
den Dateien ist unerheblich, da ohnehin sor¬ 
tiert wird. ub 

Literatur 

1] E. Meyzis, Mit System entwickeln, AMIGA 3/91. 5/91. 7/91 
9/91 und 12/91 

2] N. Wirth. Algorithmen und Datenstrukturen. Stuttgart, 1983 


1 

: IMPLEMENTATION MODULE BinaerBaum; 

2 

: FROM Arts IMPORT Assert; 

3 

: FROM DateiHandling IMPORT GetSprachlD, Spra 
che; 

4 

: FROM Storage IMPORT ALLOCATE; 

5 

: FROM SYSTEM IMPORT ADR; 

6 

: FROM Terminal IMPORT Write, WriteLn; 

7 

: PROCEDURE BaumAnlegen(VAR wurzel : BaumPtr); 

8 

: BEGIN 

9 

: ALLOCATE(wurzel, SIZE(Knoten)); 

10: Assert(wurzel # NIL, ADR('Baum nicht anlegb 
ar")); 

11 

: wurzel A .re := NIL; 

12 

: END BaumAnlegen; 

13: PROCEDURE NamenSuchen(VAR p : BaumPtr; {* im 
Baum *) 

14 

namen : ZeichenPtr; 

15 

isPascal : BOOLEAN; 

16 

VAR rel : Relation) : BaumPtr; 

17 

(* Die lokale Prozedur "Vergleiche" (zwei Ze 
ichenketten) vermeidet den rekursiven Aufruf 
von "NamenSuchen" mit dem Vorteil, keine la 
nge Parameterliste kopieren zu muessen. *) 

18: VAR q : BaumPtr; 

19: PROCEDURE Vergleiche (neu, vglWort:ZeichenPt 
r): Relation; 

20 

(* zwei Strings zeichenweise *) 

21 

VAR 

22 

rel : Relation; 

23 

BEGIN 

24 

rel:= gleich; (* vorlaeufige Annahme *) 

25 

LOOP 

26 

IF CAP(neu A ) # CAP(vglWort A ) THEN {* Zeich 
en ungleich? *) 

27 

EXIT (* Vergleich abbrechen *) 

28 

END; 

29 

IF neu A <= " * THEN (* Ende der Kette? *) 

30 

RETURN rel (* Vergleichsergebnis *) 

31 

END; 

32 

IF NOT isPascal THEN 

33 

IF neu A < vglWort A THEN (* zeichenweiser 
Vergl. *) 

34 

rel:= kleiner; 

35 

ELSIF neu A > vglWort A THEN 

36 

rel:= groesser; 

37 

END; 

38 

ELSE (* fuer PASCAL alles GROSS *) 

39 

IF CAP(neu A ) < CAP(vglWort A ) THEN 

40 

rel:= kleiner; 

41 

ELSIF CAP(neu A ) > CAP(vglWort A ) THEN 

42 

rel:= groesser; 

43 

END; 

44 

END; 


1 45: INC(neu); (* naechstes Zeichen im String*) 1 

46 

: INC(vglWort); (* • *) 

47 

: END; (* LOOP *) 

48 

: IF CAP(neu A ) > CAP(vglWort A ) THEN 

49 

: RETURN groesser 

50 

: ELSE 

51 

: RETURN kleiner 

52 

: END; 

53 

: END Vergleiche; 

54 

: BEGIN 

55 

: q:= p A .re; (* an Wurzel beginnen *) 

56 

: rel:= groesser; (* vorlaeufig *) 

57: WHILE q # NIL DO (* bis alle Knoten durchsu 
cht sind, falls vorher nicht gefunden. *) 

58 

p:= q; 

59 

rel := Vergleiche(namen, p A .wortAdr); 

60 

IF rel = gleich THEN 

61 

RETURN p (* gefunden *) 

62 

ELSIF rel = kleiner THEN 

63 

q:= p A .li {* im linken ZW 

eig weiter *) 

64 

ELSE 

65 

q:= p A .re (* im rechten Zw 

eig weiter *) 

66 : END; 

67 

END; 

68 

RETURN NIL; 

69 

END NamenSuchen; 

70 

PROCEDURE KnotenEinfueg(VAR p : BaumPtr; 

71 

rel : Relation; 

72 

namen : ZeichenPtr) : BaumPtr; 

73 

VAR q : BaumPtr; 

74 

BEGIN 

75 

ALLOCATE(q, SIZE(p A )); (* neuen Knoten *) 

76 

Assert(q # NIL, ADR("kein neuer Knoten")); 

77 

WITH q A DO 

78: wortAdr := namen; (* Nutzinf 

o eintragen *) 

79 

numList := NIL; 

80 

li := NIL; 

81 

re := NIL; 

82 

END; 

83 

IF rel = kleiner THEN 

84 

p A .li := q (* Knoten anfuegen entspr. *) 

85 

ELSE (* des Ordnungsschönas im *) 

86 

p A .re := q (* Baum. *) 

87 

END; 

88 

RETURN q; 

89 

END KnotenEinfueg; 

90 

PROCEDURE ZeigeBaum(p : BaumPtr); (* Test *) 

91 

(* fuer beide Baeume *) 

92 

PROCEDURE InfoAusgeben(p:BaumPtr); 

93 

(* gespeicherte Namen bzw. reservierte Woert 

pr M 

94 

VAR z : ZeichenPtr; 

95 

BEGIN 

96 

z := p A .wortAdr; (* Anfang der Zeichenkett 

97: 

WHILE z A > " " DO (* solange Ende Kette u 
nerreicht *) 

98 

Write(z A ); (* zeichenweise ausgeben *) 

99 

INC(z); {* auf das naechste Zeichen *) 

100 

END; 

101 

WriteLn; 

102 

END InfoAusgeben; 

103 

PROCEDURE WeiterlmBaum(p : BaumPtr); 

(* rekursiv *) 

104: 

BEGIN 

105: 

IF p # NIL THEN (* ein Knoten erreicht * 

) 

106: 

WeiterImBaum(p A .li); (* soweit im linken 
Zweig, wie es geht *) 

107: 

InfoAusgeben(p); (* dann alle zwischenz 
eitlich durchlaufenen Knoten in umgekehrter 
Reihenfolge ausgeben *) 

108: 

WeiterImBaum(p A .re); (* ab in den rechten 
Zweig*) 

109: 

END; 

110 : 

END WeiterlmBaum; 

111 : 

BEGIN 

112 : 

WriteLn; 

113: 

WeiterImBaum(p A .re); (* der linke Zweig des 
Wurzelknotens ist unbenutzt. *) 

114: 

END ZeigeBaum; 

115: 

END BinaerBaum. © 1993 M&T 

Listing 4: Die Routinen zeigen, wie ein- 

fach binäre Bäume anzulegen, zu ver- 

walten und auszugeben sind. Ähnliche 

Aufgaben werden durch wiederholten 

Aufruf eines Unterprogramms (Namen- 

Suchen) und rekursiv (WeiterlmBaum) 

erledigt, um die Einarbeitung in Baum- 

algorithmen zu erleichtern. 


100 


Faszination Programmieren Nr. I 















1: MODULE KreuzRef; (* Hauptmodul Kreuzreferenzgenerator *) 

2: FROM DateiHandling IMPORT DateienOeffnen, DateienSchliessen; 

3: FROM ReferenzBaum IMPORT ReferenzErstellen; 

4: BBGIN 

5: DateienOeffnen; 

6: ReferenzErstellen; 

7: CLOSE (* immer ausfuehren, auch bei Abbruch *) 

8: DateienSchliessen; 

9: END KreuzRef. 

10: (* Das Hauptmodul arbeitet mit vier weiteren Modulen, deren Schnittste 
llen wie folgt definiert sind: *) 

11 : (* 1111111111 *) 

12: DEFINITION MODULE DateiHandling; 

13: FROM FileSystem IMPORT File; 

14: TYPE Sprache = (Basic, C, Cpp, Modula, Pascal); 

15: (* um Sonderbehandlungen zu ermoeglichen. Cluster und Oberon firmiere 

n unter Modula-2 *) 

16: VAR wortQuelle, (* Datei mit den reservierten Woertem im Verzeichnis 
"S:\ z.B. "C.Words" *) 

17: quelle, (* zu analysierender Quelltext, z.B. "Hallo.cpp' *) 

18: senke : File; (* nimmt Kreuzreferenz auf und hat denselben Pfad wie 
"quelle', z.B. "Hallo.xrf" *) 

19: PROCEDURE FileExists(name : ARRAY OF CHAR) : BOOLEAN; (* Datei Vorhand 
en ? *) 

20: PROCEDURE GetSprachlDO : Sprache; 

21: (* ergibt sich aus dem Suffix des Dateinamens fuer den Quelltext *) 

22: PROCEDURE DateienOeffnen; 

23: (* alle drei Dateien; Programm bei Fehlem abbrechen *) 

24: PROCEDURE DateienSchliessen; 

25: (* die drei Dateien *) 

26: END DateiHandling. 

27: (* 222222222 *) 

28: DEFINITION MODULE BinaerBaum; 

29: TYPE 

30: ZeichenPtr = POINTER TO CHAR; 

31: Relation = (kleiner, groesser, gleich); (* Ergebnis des alphabetis 

chen Vergleichs von Zeichenketten *) 

32: ListPtr = POINTER TO Element; 

33: Element = RECORD (* Knoten einer einfach verketteten Liste *) 

34: zeilNum : INTEGER; (* Zeilennummer eines Namens *) 

35: next : ListPtr; (* naechstes Element*) 

36: END; 

37: BaumPtr = POINTER TO Knoten; 

38: Knoten = RECORD (* Blaetter der beiden Binaerbaeume *) 

39: wortAdr : ZeichenPtr; (* Name oder reserv. Wort *) 

40: numList : ListPtr; (* auf Liste mit Zeilennr *) 

41: li, re : BaumPtr; (* Baum verzweigt *) 

42: END; 

43: PROCEDURE BaumAnlegen(VAR Wurzel : BaumPtr); 

44: (* fuer Wurzelknoten des Baumes mit den reservierten Woertem bzw. auf 
Baum mit den Namen des zu analysierenden Programms *) 

45: PROCEDURE NamenSuchen(VAR p : BaumPtr; 

46: namen : ZeichenPtr; 

47: isPascal : BOOLEAN; 

48: VAR rel : Relation) : BaumPtr; 

49: (* in beiden Baeumen Ergebnis: NIL, wenn namen nicht gefunden, sonst A 
dresse des Knotens 

50: p: weist auf Knoten, der den gesuchten Namen enthalten muesste, fall 

s Ergebnis NIL 
51: namen: ist zu suchen 

52: isPascal: um Gross-/Kleinschreibung richtig zu handeln 

53: rel: so ging der Vergleich aus *) 

54: PROCEDURE KnotenEinfueg(VAR p : BaumPtr; 

55: rel : Relation; 

56: namen : ZeichenPtr) : BaumPtr; (* an der Stelle p im Baum *) 

57: PROCEDURE ZeigeBaum(p : BaumPtr); (* eingebaute Testroutine *) 

58: END BinaerBaum. 

59: (* 333333333 *) 

60: DEFINITION MODULE ResWortBaum; 

61: FROM BinaerBaum IMPORT BaumPtr; 

62: FROM FileSystem IMPORT File; 

63: PROCEDURE WortBaumAnlegen(wortDatei : File) : BaumPtr; 

64: {* fuer die reservierten Woerter einer Sprache *) 

65: END ResWortBaum. 

66: {* 444444444 *) 

67: DEFINITION MODULE ReferenzBaum; 

68: FROM BinaerBaum IMPORT BaumPtr; 

69: PROCEDURE ReferenzErstellen; 

70: (* spannt beide Baeume auf (res. Woerter u. Referenz), speichert das E 
rgebnis in eine Datei mit dem Namen der Quelltextdatei (im selben Pfad 
) und dem Suffix ".xrf"*) 

71: END ReferenzBaum. 

72: 

73: © 1993 M&T 


Listing 5: Unser Programm »Kreuzreferenzgenerator« besteht 
aus fünf Modulen, die recht lose gekoppelt sind. Das Modul 
»BinaerBaum« enthält die grundlegenden Routinen für die 
Arbeit mit binären Bäumen. Es wird von den Modulen »Res¬ 
WortBaum« und »ReferenzBaum« eingesetzt. 


Cr W.A.W. Elektronik GmbH C z 

Aniiga & CDTV Erweiterungen 
Advanced ChipRam Adapter 

| * Kombinierte Chip- und Fastramerweiterung für 
A 500 & A 2000 B.C oder D 

* Erweitert das Chipram um 1 MB auf 2 MB 

* Erweitert das Fastram um 2MB auf bis zu 10 MB 

* Kompatibel zu herkömmlichen Ramerweiterungen 

* Vollständig steckbar. kein löten 

* Vollständig autokonflgurierend 

* Emög. flexibleres Arbeiten im Multitasking und 
Grafikbc reich 

* Genlock kompatibel 

* Superkompakte Baubweisc durch ZIPRam's 

* Deutsche Einbau- und Bedienungsanleitung 

* Lieferung inkl. PLCC-Ausziehwerkzeug 


Advanced ChipRam Adapter 2 MB ChipRam + 2 MB Fastram DM 599.- 

2 MB ChipRam Adapter inkl. A 3000 Agnus und 1 MB Ram DM 399.- 

BigRam 5 512K Fastram DM 69.- 

BigRam 10 IMB Chip fü^ A50O+ DM 99.- 

BigRam 25 2 .5 MB Fastram für A500 DM 245.- 

BigRam 30 für A500 plus 2MB ChipAdapter inkl. 1 MB Ram DM 199.- 

BigRam 30 ADV für A50O plus 2MB ChipRam und 2 MB FastRam DM 398.- 

BigRam CD 2 MB ChipRam inkl. A 3000 Agnus und 1 MB Ram DM 399.- 

BigRam CD ADV 2 MB ChipRam + 2 MB Fastram DM 599.- 

BigRam 2008 8 MB Ram für A 2000. DM 555.- 


Zum Preis einer herkömmlichen 4 MB Erweiterung. Rechnen Sie nach !! 

CDTV to SCSI 

SCSI-Autoboot-lnterfacc für CDTV * Vollständig steckbar. kein löten * Harddisk. Streamer etc. 
anschließbar * Höchste Performance durch 16 MHz Turbotakt * Bis zu 7 SCSI-Geräte gleichzeitig 
* Interner 50 pol. Flachkabelanschluß * Externer 25 pol. D-Sub Anschluß * Abschaltbar, somit voll 
Software kompatibel * Deutsche Partionierungssoftware und Einbauanleitung . 

CDTV to SCSI Interface.DM 299.- 

wie vorher mit Harddisk 52 MB (intern).DM 899.- 

Andere Harddisk auf Anfrage. 

Alle Preise sind unverbindliche 
Preisempfehlun%en . 

WA.W. Elektro nik Gmb H 
Tegeler Str. 2 1000 Berlin 28 
Tel: 404 33 31 /404 80 38 
Fax: 404 70 39 

Vertrieb für die Schweiz: Promigos 
Hauptstr. 37 * 5212 Hausen 
_Tel: 056-322132 




VIAICCH 

Langensandstrasse 78 
6000 Luzern 12 
Schweiz 

Telefon 041 44 54 52 
Telefax 041 44 74 84 


Ihr Amiga Spezialist im 
Herzen der Schweiz 

Bei uns ist der Kunde König 
Super Service, sehr hohe 
Lieferbereitschaft und unglaubliche 
Tiefstpreise 

Wir sind Fachhändler für 
Commodore, Quantum, Fujitsu, 
EIZO, Targa, Supra, Vortex, HP 
Canon, ZyXEL, Alfa Data und viele 
weitere Produkte 
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Computertechnik 


MULTIVISION 500/2000 


Kein Interlace-Flimmern mehr! 

MV2000 wird in den Videoslot des A2000 B/C eingesteckt w ^ 

MV500 findet Platz im Sockel des Videochips (Denise) ^ 

- Volles Overscan (768 x 598 Punkte), 4096 Farben 

- 50 Hz Vollbildfrequenz, per Software (im Lieferumfang) 
bis 100 Hz einstellbar 

- Double-Scan-Modus, die schwarzen Zwischenzeilen verschwinden 

- Integrierter Stereo-Audio-Verstärker 

- kompatibel mit jeder Software 

- VGA-kompatibler Videoausgang zum Anschluß von 

VGA/Multiscan-Monitoren OQQ 

Die Leser des Amiga-Magazins wählten MultiVision 
zum Produkt des Jahres 1991 & 1992. 



FLOPPY DRIVE 3,5" 


Bus bis df3 • abschaltbar 
mit Metallgehäuse 
Made in Germany 


extern für alle Amigas • 

149,- 


CHIP 2 MB 


Adapter-Platine für A500 & A2000 B/C/D 
Erweitert das ChipRAM von 1 MB auf 2 MB 
Einfach einstecken, Einbau ohne Löten 
inkl. 1 MB RAM 
und 8375 Super-Agnus 


349,- 


A580 / A580 plus 


inkl. Uhr & Akku 
& Gary-Ad 


A580 plus 


Speichererweiterung für A500 
intern auf 2.3 MB 

249,- 


1.0 MB ChipRAM & 

2.5 MB Gesamtspeicher 
inkl. CPU-Adapter 



299,- 


MegaMix 500/2000 


2.0 MB bis 8.0 MB FastRAM-Erweiterung 
für A500 & A2000 • null Waitstates • 
autokonfigurierend • abschaltbar• fürA500 
extern im formschönen Gehäuse mit 
durchgeführtem Systembus 

MegaMix 500 RAM-Box 
mit 2.0 MB 

MegaMix 2000 RAM-Karte 

mit 2.0 MB 249 ,- 

je weitere 2.0 MB 150,- 




APOLLO 500/2000 


Top-Performance ohne DMA-Probleme! 

- Höchste Geschwindigkeit durch neuen 3-State Custom-Chip: 
Übertragungsrate bis zu 1.6MB/sec mit 68000-CPU 

- In Verbindung mit Turbokarten setzt Apollo neue Maßstäbe! 

Statt langsamer 16Bit-DMA überträgt die CPU mit vollen 32Bit und 
erreicht mit Apollo Übertragungsraten von 2.5 MB/sec und mehr. 


NEU! Jetzt mit Apollo-Software Version 2.0 


Volle Wechselplatten-Unterstützung mit Auto-Diskchange 
Write-Cache und Read-Prefetch-Cache für superschnelle File-Operationen 
Chamäleon-Support (Atari-ST-Emulator) 


SCSI-Direct & AT-Direct 

Apollo 2000 ohne RAM/HD 

299 ,- 

mit Harddisk 

42 MB 

699 ,- 



mit Quantum 

85 MB 

799 ,- 



mit Quantum 

127 MB 

899 ,- 

RAM-Erweiterung um 2 MB 

150 ,- 

mit Quantum 

170 MB 

1049 ,- 

Apollo 500 ohne RAM/HD 

349 ,- 

mit Harddisk 

42 MB 

749 ,- 



mit Quantum 

85 MB 

849 ,- 



mit Quantum 

127 MB 

949 ,- 

RAM-Erweiterung um 2 MB 

150 ,- 

mit Quantum 

170 MB 

1099 ,- 


£ 








AT-APOLLO 500/2000 


16-Blt AT-Bus-Controller für A500 oder A2000 


AT-Apollo 

2000 


AT-Apollo 500 


ohne HD 


199 ,- 

ohne HD 


249 ,- 

mit Harddisk 

42 MB 

599,- 

mit Harddisk 

42 MB 

649,- 

mit Quantum 

85 MB 

699,- 

mit Quantum 

85 MB 

749,- 

mit Quantum 

127 MB 

799,- 

mit Quantum 

127 MB 

849,- 

mit Quantum 

170 MB 

949,- 

mit Quantum 

170 MB 

999,- 

RAM-Option 2-8 MB für AT-Apollo 500, mit 2.0 MB 

299 ,- 


Händlerdistribution Inland/Ausland 

Sie sind Computerfachhändler mit einem Versand- oder Ladengeschäft und wollen auch 
AMIGA- und 3-State-Fachhändler werden. Dann wenden Sie sich mit Gewerbenachweis 
an unseren Distributor, Sie erhalten umgehend weitere Informationen. 


Händlerdistribution: 

Colossus Computer GmbH 
Daimlerstr. 6b 
W-4650 Gelsenkirchen 2 
Fax: 0209/779236 


Alle genannten Preise sind unverbindliche Preisempfehlungen • Änderungen Vorbehalten • Lieferung nur zu unseren allgemeinen Geschäftsbedingungen • Mit dieser Preisliste verlieren alle vorherigen ihre Gültigkeit. 

















































INTERN 


EGS 

Die Zahl der Grafikkarten für den 
Amiga steigt. Das veranlaßte 
einige Entwickler, eine uniforme 
Programmierschnittstelle zu schaf¬ 
fen. Ein Hintergedanke war es, 
die auf anderen Computern herr¬ 
schende Verwirrung, durch viele 
Grafikkarten und Programme mit 
verschiedenen Softwaretreibern, 
zu vermeiden. 

von Stefan Herr, Thomas Pfrengle und 
Ulrich Sigmund 

D as Ergebnis ist EGS: »Extended Gra¬ 
phics Standard« für den Amiga. Die 
Entwickler versuchten, eine für das 
Amiga-System passende Lösung zu erarbei¬ 
ten. Deshalb besteht EGS aus einer Samm¬ 
lung von Bibliotheken (Shared Libraries), die 
auf Amiga-spezifische Weise benutzt wer¬ 
den. Weiterhin wurde versucht, sich an den 
bisher im Amiga-System existierenden Da¬ 
tenstrukturen und Funktionen zu orientieren, 
damit der bisher nur mit »Intuition« und 
»Graphics« beschäftigte Programmierer vie¬ 
les aus seiner vertrauten Umgebung wieder¬ 
findet. 

Die EGS-Bedienereroberfläche läßt sich 
mit Hilfe von VoreinstellungspProgrammen 
(»EGS Preferences«) variieren. Sie ermögli¬ 
chen es sogar, die EGS-Oberfläche nach den 
Commodore-Richtlinien (»Intuition Interface 
Style Guide«) zu gestalten. Unter EGS lau¬ 
fende Programme sind vorbereitet, die vom 
Benutzer definierten Vorgaben zu verwen¬ 
den. Hiermit ergibt sich die größtmögliche 
Einheit der Bedieneroberfläche. 


EGS-Features 


EGS hat eine frei konfigurierbare Ober¬ 
fläche; Fenster lassen sich aus dem sichtbaren 
Bildschirmbereich herausschieben; virtuelle 
und reale 24-Bit True-Color-Grafik; Fenster, 
Gadgets, Menüs usw. sind Font-Sensitiv; Pop- 
Up-Menüs; am Fenster montierte und bewegli¬ 
che Menüs; Menüs lassen sich von verschiede¬ 
nen Fenstern teilen; gesteigerte Performance 
von EGS durch optimiertes Layering; Fenster 
kann man mit Inhalt verschieben; Verfügbar 
für die Amiga-Chipsätze »Standard« und 
»ECS« (»AA« in Kürze); folgende Grafikkarten 
unterstützen EGS: »VISIONA«, »EGS HO«, 
»IV-24«, »RAINBOW II«, »RAINBOW III«, 
»RAINBOW III entry«, »DOMINO« (über 
Zweitanbieter), »COLORMASTER« in Kürze 
über Zweitanbieter. 


Grafikstandards 

was ist das? 



Worfclr 
PlayM« 
Pr int 1 
Saarct 


jclipboard.doc 

•gsgadbox.doc 

intuition.doc 


Save Clip 


Wmdow (Active) Gadget (Selected) 


Pattem -(•?. infc) 


■I" n — || 

i| tniuiüondoc 




No other gadgets may be in usa.Thia includea syst 

such as those for window eizing, dragging, etc. 

If th« gadget is in a requester, tnat requester mus 
ba active. (Use IDCMP.REQ3ET and IDCMP_RBQCLRAR). 
The right mouae button cannot be held down (e.g. me 


NOTE: Don't try to aotivate a gadget which ia disabled 
- No other gadgets may be in uae. This includes sys 


This includea syst 

dragging, etc. 
hat requeater mus 


auch as thoae for window aizing 


If the gadget is in 
be active. (Uae IDF 
The right mouae bu 


Block Start 

Block end 

Block hide 

Cut 

Copy 

Paste 

Delete 


NOTE: Don't try to act 
not attached to a wind 


Directones 


FM 


egs.doc 

egablit.doc 

egsgadbox.doc 

egagfx.doc 

egalntui.doc 

egsintuigfx.doc 

egslayers.doc 

egarequeat.doc 

gbmenuselect.doc 

gbradio.doc 


ACOM 

AINC 

ALIB 


Moum 


Die EGS-Oberfläche: True-Color-Darstellung bedeutet, daß immer mit 24 Bit 
bzw. 16,8 Millionen Farben gearbeitet wird - unter EGS kein Problem 


Virtuelle 24-Bit-Umgebung 

EGS-typisch ist, daß intern stets mit 24-Bit 
Farbtiefe (»True Color«) gearbeitet wird. 
Besitzt jedoch die momentan verwendete 
Grafikkarte bzw. der aktuelle Bildschirmmo¬ 
dus keine True-Color-Darstellung, werden 
die intern verwendeten 24-Bit-Farben in die 
darstellbaren umgerechnet. Hierzu verwendet 
EGS die Dithering-Technik sowie ein intelli¬ 
gentes Farbauswahlverfahren. 

Der Vorteil: Die verfügbaren Farben eines 
Bildschirmmodus werden voll genutzt. Wei¬ 
terhin vereinfacht dieses Prinzip die Entwick¬ 
lung von Grafiksoftware, da ein Programm 
immer nur auf eine Farbtiefe (und zwar 24 
Bit) eingehen muß. 

Architektur von EGS 

EGS ist eine Sammlung von Laufzeitbi¬ 
bliotheken, die wie Standard-Exec-Bibliothe- 
ken zu benutzen sind. Sie dienen dem hard¬ 
wareunabhängigen Gebrauch von Grafikkar¬ 
ten auf dem Amiga. Sie stellen hierzu eine 
Vielzahl von Funktionen bereit, die Manipu¬ 
lationen des Bildschirminhalts einer Grafik- 
karte auf mannigfaltige Weise ermöglichen. 
Diese Manipulationen können auf vier ver¬ 
schiedenen Ebenen stattfinden: 

□ Auf der höchsten Ebene 4 finden man Bi¬ 
bliotheken, die den Entwurf von Bediener¬ 
oberflächen erleichtern. Sie schaffen via ein¬ 


facher Beschreibungssprache Kommunika- 
tionsselemente, z.B. Gadgets und Requester. 

□ Auf der nächsttieferen Ebene gibt es 
Bibliotheken, die Funktionen zur Verwaltung 
der Bedieneroberflächen bereitstellen. Hierzu 
gehören die in Ebene 3 dargestellten Biblio¬ 
theken (s. Bild). Sie enthalten Funktionen, 
die eine ähnliche Benutzerschnittstelle wie 
Commodores Intuition implementieren, z.B. 
Screens oder Windows. 

□ Auf der darauf folgenden Ebene stehen 
Bibliotheken mit Funktionen zur direkten 
Manipulation von Bitmaps und ihrer Überla¬ 
gerung (Layers) zur Verfügung. Dies ent¬ 
spricht Ebene 2. Die hier vorhandenen 
Bibliotheken haben ihr Pendant in Commo¬ 
dores Graphics- und Layers-System. 

□ Auf der untersten EGS-Ebene (Ebene 1) 
befinden sich die für die Abstrahierung der 
Grafikhardware zuständigen Bibliotheken. 
Sie stellen Low-Level-Zeichenfunktionen 
sowie Funktionen zur prinzipiellen Verwal¬ 
tung der Grafikkarte und ihrer Darstellungs¬ 
modi bereit (EGS.library). Weiterhin existie¬ 
ren hier noch Funktionen zur Verschiebung 
und Konvertierung von Grafikspeicheraus¬ 
schnitten (EGSBlit.library). 

Alle oben erwähnten Ebenen basieren auf 
der Grafikkartenhardware sowie dem Amiga- 
Betriebssystem an sich (hauptsächlich der 
exec.library). Das entspricht Ebene 0. 
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EGSRequest 

High-Level-Requester 
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GBScrollBox 

GBRadio 

GBSets 

GBSelect 

GBMenu-Select 

GBTextlnfo 

Lisrviewselect- 

Gadgets 

Radiobuttons 

Set-Gadgets 

Toggleselect- 

Gadgets 

Menuselect 

Informalionbox 
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EGSGadBox 

Gadgct-Konslruktion 
und Management 




Ebene 3 


EGSlntui 

iü 

IntuiGfx 

High-I^vel-Support von 
Windows. Screens, Menüs 

nsisssfäss 

Intuition-Rendering- 
Elemente. u.a. Stacksprache 
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Ebene 2. 






Ebene 1 
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Ebene 0 


EGSGfx 

High-Level-Drawing- 

Functions 


_ 


iEEjfliislskljl 


EGSLayers 
Layers, Low Level 
Window-Support 


• :.! : : : : 


^ EGS 

Basic-Viewmanagement 

Bitmap-Management 

Inputmanagcment 






Am iga-Betriebssystem 






EGSBIit 

Basic-Drawing-Functions 
Bilmap-Conversion 






Grafikkarten-Hardware 
BI i tter/Fra mebu ffer 


Aufbau von EGS: Die fünf verschiedenen Ebenen bieten für jede Software¬ 
anpassung die gewünschten Fähigkeiten und Eigenschaften 


Je nachdem, welche Komplexität bzw. 
Anforderungen (Geschwindigkeit, Flexibili¬ 
tät) ein zu entwickelndes Programm fordert, 
entscheidet sich der Programmierer für eine 
der vier EGS-Ebenen. Am komfortabelsten 
und somit wohl am häufigsten benutzt wer¬ 
den die oberen beiden Ebenen 3 und 4. Für 
einfache Grafikausgaben, die auf ein Fenster¬ 
system verzichten können, verwendet man 
Ebene 2. Die untere Ebene ist dafür gedacht, 
besonders schnell mit der Grafikhardware zu 
arbeiten (allerdings immer noch hardwareun¬ 
abhängig). 

Kompatibilität und Portierbarkeit 

Für etliche Grafikkarten und auch die 
Amiga-Grafikchipsätze (Standard, ECS) exi¬ 
stiert eine EGS-Anpassung. Die fürs AA- 
Chipset folgt in Kürze. Hierfür müssen ledig¬ 
lich die »egs.library« und »egsblit.library« 
für die jeweilige Grafikhardware angepaßt 
werden. Programmen bleibt dabei völlig ver¬ 
borgen, welche Grafikkarte verwendet wird. 
Ein EGS unterstützendes Programm läuft 
ohne Änderung auf allen von EGS unterstütz¬ 
ten Grafikplattformen. 

Grundsätzlich ist jedes für Intuition oder 
Graphics geschriebenes Programm aufs EGS- 
System portierbar. EGS stellt gerade hierfür 
ähnliche Funktionen und Datenstrukturen wie 
das Amiga-System bereit. Einige Dinge sind 
jedoch zu beachten: 

□ Viele Datenstrukturen wurden erweitert 
und in vielen Fällen erheblich in der Funktio¬ 
nalität ergänzt. Dies folgt daraus, daß EGS 
auf 24 Bit (True Color) beruht, was natur¬ 
gemäß einen größeren Leistungsumfang 
bedingt. Es kann daher nicht überall eine 1:1- 
Übereinstimmung mit den Amiga-Daten- 
strukturen erwartet werden. Ähnliches gilt 
auch für die Bibliotheksfunktionen und ihren 
Aufruf. 


□ Es bestehen gegenüber dem Amiga- 
System Unterschiede in der Bezeichnung der 
Datenstrukturen und ihrer Elemente sowie 
der Bezeichnung der Funktionen und ihrer 


Argumente: So ist eine bessere Unterschei¬ 
dung der EGS-Bezeichner bei gleichzeitiger 
Verwendung der dem Amiga-System zu¬ 
gehörigen möglich. 

Vorteile von EGS 

Die Portierung eines Programms auf EGS 
bietet einige Vorteile, u.a. die völlige Unab¬ 
hängigkeit der Programme von der Grafik¬ 
hardware sowie der Unabhängigkeit von der 
Grafikdarstellung, Auflösung und Farbtiefe. 

Vertriebs weise 

Das EGS-System wird von den Grafikkar¬ 
tenherstellern lizenziert und vertrieben. Somit 
muß ein Programmierer für EGS keine 
Gebühren für Nutzungsrechte entrichten. 
Auch die Käufer der Grafikkarten profitieren 
von dieser Verfahrensweise, da sich die von 
ihnen gekaufte EGS-Software auf allen Kar¬ 
ten gleich verhält und auch gleich aussieht. 

Haben Sie Interesse, Programme unter der 
EGS-Oberfläche zu entwickeln, wenden Sie 
sich bitte an: 

Viona Development 
Dreiherrenstein 6a 
6200 Wiesbaden-Auringen 

Sie erhalten dort weitere Informationen 
und Unterstützung. Softwareentwickler erhal¬ 
ten die Amiga-Implementation unentgeltlich. 

rz 
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Vesalia 


AMIGA-Hardware 


AMIGA 600 und 1-MB-Karte 

720,- 

AMIGA 600 - 40 MB 1 MB - Karte 

1099,- 

PHILIPS CM 8833 II Stereo-Farbmonitor 

459,- 

AMIGA 1200 inkl. 84 MB-HD 

1549,- 

AMIGA 2000 2x3,5 ’ LW u. 8/2 MB - Karte 

1398,- 

AMIGA 2000 inkl. PC 386- Karte 

1698,- 

AMIGA 2000 und 14" VGA Monitor ab 1998,- ? 

ind. Interlace-Karte, 2 x 3.5" LW und 8/2 MB-Karte 

AMIGA 3000 incl. 52 MB-HD 

2598,- 

AMIGA 4000 incl. 40 MB-HD 

3799,- 

AMIGA 4000 incl. 120 MB-HD 

4099,- 

14" SVGA-PHILIPS-Monitor 

1024 x 768,0,28mm, MPRII. 

998,- 

AMIGA - Speichererweiterungen 

WINNER- RAM - Made in Germanv 

5 Jahre Garantie 


512 KB - WINNER-Ram A 500 - intern 
abschaltbar, mit Uhr/Akku, Megabittechnik 

59,- 

1,0 MB - RAM- Karte A 500-Plus - intern 89,- \ 

1,0 MB - RAM-Karte A 600 - intern 

129,- 

1.0 MB Memory S-RAM-Card A6CKV1200 478,- 
2.0 MB Memory D-RAM-Card A6(xyi200 298,- 
4.0 MB Memory D-RAM-Card A60Q/12Q0 548,- 
8/2 MB-WINNER-Rambox A500/500Plus 298,- 

Aufrüstung um weitere 2 MB 

140,- 

8/2 MB - RAM-Karte A 2000 - intern 

229,- 

Aufrüstung um weitere 2 MB 

140,- 

AMIGA - Laufwerke 

3,5' Promiaos - Drive - extern 
abschaltbar, Kunststoffgehäuse 

100,- 

3,5" WINNER- Drive -extern 
abschaltbar, Metallgehäuse. MitTurbo - Copy. 

3,5" Laufwerk A 500 - intern 
kompl. mit org. Auswurftaste und Zubehör 

3,5" Laufwerk A 2000 - intern 
komplett mit Einbauanleitung und Zubehör 

S $ 

1 1 

96,- 

3,5' Laufwerk A 3000 - intern ( 880 KB) 

129,- 

5,25" Laufwerk -extern 

179,- 

Genlock, Digitizer usw. 


FrameMachine 

798,- 

Superschneller Echtzeitdigitizer 16 Mill. Farben, 
S/W 18 Bilder Sek. Standart mit Turbokarte oder 

A 3000 in Echtzeit 


Erweiterungsboard ( 24 Bit Grafikkarte) 

Einfach auf FrameMachine aufstecken 

698,- 

FrameMachine und 24-Bit Grafikkarte 1398,- 

Pal-Genlock3.0 

648,- 

Y-C-Genlock 5.0 SVHS und Hi8 

988,- 

Sirius-Genlock 2.0 

1480,- 

digitale Standbildsynchronisation 

Video - Konverter, 

298,- 

Video und Y£ Signale vom A2000 

Y-C Colorsplitter, vollautom. RGB Splitter 

388,- 

Videodigitizer 819 A 2 /3/4000 

Echtzeit Framgrabber A 2/3/4000 

298,- 

V-Lab A 2/3/4000 Echtzeit Videodigitizer 

545,- 

V-LabS-VHSA 2/3/4000 

595,- 


COMPUTER 


Retina Grafikkarte 548,- 

1 MB - RAM 24 Bit 16,7 Mill.Farben 

Framestore Echtzeitdigitizer 875,- 

AMIGA-Zubehör 

2-fach ROM-Umschaitplatine 89,- 

Für AMIGA 600 / 600- HD incLROM 1.3 

2-fach ROM-Umschaltplatine o. Schalter 39,- 

2-fach ROM-Umschaltplatine 69,- 

mit org. ROM 1.3 für A 500Plus / A2000 neu 

2-fach ROM-Umschaltplatine 119,- 

mit ROM 2,0 für AMIGA 500 /2000 alt 

elektr. Bootselektor DFO - DF3 39,- 

WINNER-Sound-Sampler. Unser Renner 89,- 

Stereo-Sound bis 50 KHz, Umwandlung bis 800 KHz, 
Mikrophonanschluß: Eingänge regelbar, mit Software 

WINNER-Midi+ 89,- 

durchgeführter serieller Bus, 

Track-Anzeige A2000 -intern 98,- 

Disketten-Box, für 100 Stück 3,5" Disketten 100,- 
inkl. 100 Stück 3,5“ 2DD Disketten 

Disketten-Box, für 100 Stück 2D-Disk. 60,- 
inkl. 100 Stück 5,25" 2D Disketten 

100 Stück 3,5" DD Disketten 90,- 

100 Stück 5,25" DD Disketten 40,- 

100 Stück 3,5' H D Disketten 160,- 

100 Stück 5,25" HD Disketten 70,- 

Infrarot Maus (Alfa Data) 99,- 

OPTO-Maus (Alfa Data) 69,- 

Volloptische Mouse (ohne Kugel) inkl. Pad u. Halter 

WINNER - Maus, 300 DPI, 2 Jahre Garantie 49,- 
in weiß, schwarz, rot oder rot-transparent 

Fancy-Maus,weiß,Amiga/Atari 39,- 

Hand-Crystal-Trackball, 400 DPI 69,- 

mit leuchtender Kristallkugel und Tastaturhalter 

Trackball( Alfa Data) 59,- 

Hand - Scanner 400 DPI, incl. Software 249,- 
A 520 HF- Modulator (AMIGA an TV-Gerät) 59,- 

MouStick autom. Maus-/Joystick-Umschalter 29,- 
Für alle Amigas, ausser A 2000 / 2500 

Maus-Master autom. UmschalterfüralleAmigas 39,- 

Interlacekaiten 

Ricker - Rxer A 500 219,- 

Flicker - Fixer A 2000 219,- 

Beide 2.0 kompatibel. 50 Hz Vollbildfrequenz bis 100 Hz 
einstellbar, volles Overscan, VGA / Multiscan-Ausgang, 
Stereo-Verstärker 


TIP DES MONATS 


alles für nur 


DM 79,- 


C £ Commodore 

AMIGA 

6 Jahre VESALIA * WINNER-Produkte = Made in Germany * 6 Jahre WINNER 


SCSI Harddisk 


MasterCard MC 702 

Test in Amiga 1 0/92 " Sehr gut" 

298,- 

85 S-ELS + MasterCard - A 2000 

898,- 

127 S-ELS + MasterCard - A2000 

998,- 

170 S-ELS + MasterCard - A 2000 

1198,- 

240 S-LPS MB MasterCard - A2000 

1498,- 

zusätzl. 2 MB - RAM -Erweiterung 

140,- 

MultiEvelution-Controller A 500 

298,- 

85 S-ELS + MultiEvolution - A 500 

878,- 

127 S-ELS + MultiEvolution -A500 

998,- 

170 S-ELS +MultiEvolution - A500 

1198,- 

240 S-LPS+MultiEvolution -A500 

1498,- 

zusätzl. 2 MB-RAM-Aufrüstung 

140,- 

AT-Bus-Harddisk 


52 MB Mastercard-A2000 

689,- 

127 MB Mastercard-A2000 

998,- 

240 MB Mastercard-A2000 

1398,- 

zusätzl. 2 MB-RAM-Aufrüstung 

140,- 

Alfa-Power A 500 / 500Plus 

externer Controller mit RAM - Option 

298,- 

Alfa-Power A 500 mit 42 MB 

698,- 

Alfa-Power A 500 mit 84 MB 

898,- 

Alfa-Power A 500 mit 127 MB 

998,- 

Alfa-Power A 500 mit 170 MB 

1098,- 

Alfa-Power A 500 mit 240 MB 

1398,- 

Aufrüstung um 2 MB 

140,- 

Ersatzteil - Service 


Kick-ROM 1.3 

55,- 

Denise 

63,- 

ECS - Denise 8373 

89,- 

I/O Baustein 8520 

29,- 

Big Fat Agnus 8372 A 

89,- 

Netzteil, A 500 4,5 A stark 

89,- 

HD - Schaltnetzteil 

109,- 

Tastatur Amiga 2000 

199,- 

Kick - ROM 2.0 org. 

99,- 

EnhancerKitorg. 

199,- 

Garry 5719 

35,- 

Tastatur A 500 

179,- 

BFA-8372 A/B 

95,- 

Netzteil A 2000 

229,- 

C 64 Netzteil neu 

49,- 

1541II Netzteil 

69,- 






INTERN 


Portable Applikationen 

Amiga vs. Windows 



Bild 1: Der Programm-Manager von Windows entspricht in etwa der Work- 
bench des Amiga. Die tolle Farbenvielfalt gibt's unter OS 2.0/3.0 jetzt auch. 


Seitdem es Windows 3.0 gibt, wol¬ 
len auch die PC-User ihre Ma¬ 
schinen nur noch mit der Maus 
dirigieren. 13 Millionen Pakete 
weltweit wurden schon verkauft 
und monatlich kommt eine Million 
hinzu. Da sollte es sich lohnen, 
Amiga-Programme umzuschrei¬ 
ben. Wir sagen Ihnen, was Sie 
dabei erwartet. 

von Peter Wollschlaeger 

W ir wollen ja nicht lästern: Daß die 
grafische Bedienoberfläche des 
Amiga der schlichten DOS-Shell 
haushoch überlegen ist, wissen wir schließ¬ 
lich selbst seit Jahren am besten. Fragt sich 
nur, warum die PC-Gemeinde erst jetzt 
umschwenkt? Die Antwort: Vorher gab es 
nur eine Pseudografik im Textmodus, und die 
überzeugte niemanden. Erst Windows 3.0 
brachte dem PC das Amiga-Feeling, und seit¬ 
dem - oder deshalb - ist Windows das er¬ 
folgreichste Softwarepaket aller Zeiten. 

Wie beim Amiga basiert Windows auf dem 
DOS und wird sinngemäß wie die Work- 
bench gestartet, nachdem das System in der 
Startup-sequence (»AUTOEXEC.BAT« und 
»CONFIG.SYS«) konfiguriert wurde. Von 
Haus aus meldet es sich mit dem Programm- 
Manager (Bild 1). Ein anderes Startpro¬ 
gramm einzutragen, bedeutet lediglich, eine 
Zeile in der Textdatei »WIN.INI« anzupas¬ 
sen. Wenn Sie sich also eine bessere Ober¬ 
fläche produzieren wollen - noproblem: 
Doch in diesem Markt gibt's schon einige 
Wettbewerber. 

Windows ist ein »non preemptive«-Multi- 
tasking-System, sieht man einmal davon ab. 


Sa i 

Bild 2: Gute Entwicklungssysteme für 
Windows sind selbst Windows-Appli¬ 
kationen. Abgebildet ist der C-Compi- 
ler »Quick C/Windows« (Microsoft). 


daß auf 386ern mehrere DOS-Tasks (keine 
Windows-Tasks) wirklich parallel laufen 
können. Im Normalfall hat von mehreren 
offenen Programmen nur eines den Fokus, 
verfügt also über die Tastatur, die Maus und 
den Bildschirm und kann die Kontrolle für 
alle Ewigkeiten behalten. Einzige Ausnahme: 
Das Programm fragt Windows, ob der User 
die Tastatur oder die Maus betätigt hat. In 
diesem Fall geht die Kontrolle an Windows 
zurück, das dann einem anderen Task die 
Systemressourcen zuteilen kann. 

Dieses kooperative Multitasking-System 
setzt voraus, daß sich die Anwendungspro¬ 
grammierer an einige Spielregeln halten; 
beim Amiga ist das ähnlich. So sollte man in 
zeitintensiven Programmteilen mit einem 
Funktionsaufruf periodisch die Kontrolle an 
Windows übergeben oder im Minimum den 
User durch die Änderung des Mauszeigers in 
ein Sanduhr-Symbol informieren. 

Noch zwei Unterschiede: Windows kennt 
zwar zahllose Bildschirmauflösungen und 
Farbtiefen von monochrom bis über 16 Mil¬ 
lionen Farben - ändert man sie allerdings, ist 
Windows neu zu starten. Während des 
Betriebs gibt's nur einen Screen. Der zweite 
Unterschied ist hardwarebedingt. Die Sound¬ 
fähigkeiten des PC sind praktisch gleich Null. 
Ohne Soundkarte, und die hat kaum jemand, 
können Sie das Thema vergessen. 

Doch nun zur Praxis. Listing 1 zeigt ein 
simples Intuition-Programm, das ein Fenster 


öffnet und »Hallo Welt!« hineinschreibt. 
Dazu wird eine Window-Struktur mit Daten 
gefüllt. Diese Pflichtkür werden Sie auch im 
Windows-Listing antreffen. Der Unterschied 
beginnt beim Öffnen der Libraries. Dazu gibt 
es zwar mit der »DLL« (Dynamic Link Lib¬ 
rary) ein Pendant in Windows, doch die 
Übereinstimmungen sind gering. DLLs wer¬ 
den von den Anwendungsprogrammierem 
geschrieben und von Windows verwaltet. Die 
Folge: Kein Windows-Programm benötigt 
eine DLL, und ein Programm muß eine DLL 
auch nicht schließen. Die Einstimmigkeit 
besteht lediglich darin, daß auch eine DLL 
nur einmal geladen wird und dann allen 
Tasks zur Verfügung steht. 

Nachdem das Window geöffnet ist, wird 
ein Rastport beschafft. Dessen Windows- 
Pendant heißt »DC« (Device-Context), und 
wie hier, verlangen auch alle Windows-Gra¬ 
fikfunktionen den DC als Argument. Der 
Unterschied: Die Standardtextausgabe »Text- 
Out()« will auch gleich die Cursor-Koordina¬ 
ten sehen. Listing 1 wartet dann mit »Wait()« 
auf eine Close-Message und endet. 

Die gleiche Aufgabe in Windows löst 
Listing 2. Das Programm ist zwar Ihnen 
zuliebe etwas ausführlicher kommentiert, 
doch eines stimmt schon: Windows-Pro¬ 
gramme sind länger. Das erste Problem: Sie 
schreiben relativ viel Code, den Sie selbst nie 
aufrufen. In der Praxis stört das nicht, denn 
diese Blöcke lassen sich als Include-Dateien 
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oder als DLL einbeziehen oder mit einem 
CASE-Tool automatisch erzeugen, doch das 
Prinzip möchte erst einmal verstanden sein. 
Die Funktionen, die Sie nie selbst aufrufen, 
nennt man Callback-Funktionen. Sie sind 
sehr einfach am Schlüsselwort »PASCAL« 
oder »CALLBACK« zu erkennen. Das 
bedeutet lediglich, daß die Parameterüber¬ 
gabe nicht nach der C-, sondern nach Pascal¬ 
konvention erfolgt (von. links nach rechts). 
Diese Vorgehensweise hat den Vorteil, daß 
sie schneller ist und das aufrufende Pro¬ 
gramm den Stack nicht korrigieren muß. Der 
Nachteil: eine variable Anzahl von Funkti¬ 
onsargumenten ist in Pascal nicht möglich. 

Die erste Callback-Funktion »WinMainO« 
ist logisch: Es ist der Entry-Point des Pro¬ 
gramms. Die Funktion ruft Windows beim 
Programmstart auf. Der Name WinMain ist 
obligatorisch, alle anderen Funktionsnamen 
dürfen Sie selbst vergeben. Schon im Funkti¬ 
onskopf tauchen einige Begriffe auf, die Sie 
kennen müssen. Da ist zuerst »Handle«. 
Nahezu alle Objekte in Windows, ob Fenster, 
Menüs, Fonts und sogar Speicherblöcke, wer¬ 
den über Handles angesprochen. Ein Handle 
ist nichts weiter als eine Kennzahl vom Typ 
Wort, die Windows verteilt und verwaltet. 

Klassengesellschaft 

Der nächste Unterschied sind die Instan¬ 
zen. Ein Windows-Programm läßt sich mehr¬ 
mals starten. Möchten Sie beispielsweise 
zwei verschiedene Texte gleichzeitig bearbei¬ 
ten, öffnen Sie den Editor zweimal, und 
schon lassen sich Textausschnitte über die 
Zwischenablage transportieren. Doch tatsäch¬ 
lich werden nur weitere Datenbereiche ange¬ 
legt, der Code befindet sich nur einmal im 
Speicher. Das Problem dabei: Diese Instan¬ 
zen müssen dieselbe Windows-Klasse nutzen 
wie das erste Programm, womit wir erst ein¬ 


mal diesen Punkt aufklären müssen. Sie kön¬ 
nen nicht direkt ein Window anlegen, son¬ 
dern müssen zuerst eine Klasse schaffen, man 
sagt auch, die Klasse muß (von Windows) 
registriert werden. Von einer Klasse lassen 
sich dann diverse Fenster(-Objekte) ableiten. 
Die Fenster können unterschiedlich aussehen, 
doch bestimmte Eigenschaften erben alle 
Fenster von ihrer Klasse. 

Zurück zu den Instanzen: Wenn Windows 
WinMain beim Programmstart aufruft, kann 
das sein erster Versuch sein, es kann aber 
damit auch die zehnte Instanz starten wollen. 
Deshalb übergibt Windows in »hlnstance« 
das Handle der neuen Instanz und in »hPrev- 
Instance« das Handle des Vorgängers. Wenn 
letzteres Handle Null ist, gibt es noch keinen 
Vorgänger und es ist der erste Start. Nur in 
diesem Fall darf eine neue Klasse registriert 
werden, was hier durch den Aufruf der Funk¬ 
tion »nCwRegisterClassesO« geschieht. 

Die Bits »CS_HREDRAW« und »CS_- 
VREDRAW« bestimmen, daß das Fenster 
aktualisiert werden soll, wenn der Anwender 
die horizontalen oder die vertikalen Rollbal¬ 
ken einsetzt. Hier steckt also die Refresh- 
Methode, die man unter Intuition beim Win¬ 
dow-Anlegen definiert. Hier definiert man 
auch den Default-Mauszeiger, legt die Hin¬ 
tergrundfarbe fest und definiert das Default- 
Menü für alle Instanzen. 

Zurück zur WinMain-Funktion: Egal, ob 
die Klasse neu angelegt wurde oder ob es Sie 
schon gibt, auf jeden Fall wird jetzt ein erstes 
oder ein weiteres Fenster benötigt. Das macht 
»CreateWindowO«. Auffallend ist die Ähn¬ 
lichkeit mit dem »OpenWindow()«-Aufruf 
von Intuition, nur daß hier die Steuer-Bits für 
die Gadgets anders bezeichnet sind. Win¬ 
dows gibt für das neue Fenster ein Handle 
zurück oder Null, wenn etwas beim Anlegen 
schiefging. In letzterem Fall wird mit »Mes- 


Insert Menu Item 


"Style 
<§> String 
O Separator 
O Bitmap... 


Name: 

Ö&ffnen 



Accelerator: 

CTRL+O 




"Initial State 

<!§> Active O Checked 


O Grayed 


" Link to 


Dialog Box 


Configure Link... 


OK 

I 

Cancel 


Help 


Bild 3: Die gesamte Oberfläche wird 
mit Ressource-Editoren erzeugt. Hier 
wird beispielsweise ein Menüeintrag 
mit einem solchen Editor definiert. 

sageBox()« ein Dialog auf den Schirm 
gebracht. Hier ist anzumerken, daß unter 
Windows Dialoge (Requester) wesentlich 
einfacher anzulegen und handzuhaben sind. 

Nach dem »ShowWindow()«-Aufruf ist 
das Fenster auf dem Schirm und das Pro¬ 
gramm geht in die Message-Loop. Die 
WHILE-Schleife läuft und läuft, bis eine 
Quit-Message eintrifft. Messages werden mit 



Hinclude <exec/types.h> 

#include <intuition/intuition.h> 

struct IntuitionBase *IntuitionBase; 
struct GfxBase *GfxBase; 

/* Struktur für neues Window initialisieren: 
struct NewWindow NewWindow = 

{ 


10 
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12 

13 

14 
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22 
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26 

27 

28 

29 

30 

31 

32 

33 

34: main() 


}; 


170,80, 

300,100, 

- 1 ,- 1 , 

CLOSEWINDOW, 

WINDOWCLOSE 
WINDOWSIZING 
WINDOWDRAG 
WINDOWDEPTH 
SMART_REF RESH 
ACTIVATE, 

NULL, 

NULL, 

•Mein Window“, 
0 , 

NULL, 

100 , 

30, 

640, 

256, 

WBENCHSCREEN 


linke obere Ecke 
Breite u. Höhe 
Farbe der Pens 
Meldung wenn 

Window-Gadgets 


Refresh-Art 
aktiv nach OpenO 


keine User-Gadgets */ 
keine User-CheckMark */ 


Window-Titel 
Kein eigener Screen 
keine SuperBitmap 
Mindestbreite 
Mindesthöhe 
Maximalbreite 
Maximalhöhe 
Bildschirmtyp 


{ 


struct Window *Window; 
struct RastPort *rp; 

/* Zwei Libraries öffnen, bei Fehler Exit: */ 

IntuitionBase = 

(struct IntuitionBase *) OpenLibrary("intuition.library“,OL) ; 
if (IntuitionBase == NULL) exit(FALSE) ; 


43: 

44: GfxBase = 

45: (struct GfxBase *) OpenLibrary("graphics.library",0L); 

46: if (GfxBase == NULL) 

47: { 

48: CloseLibrary(IntuitionBase); 

49: exit(FALSE); 

50: } 

51: 

52: /* Window öffnen, bei Fehler Exit: */ 

53: Window = 

54: (struct Window *) OpenWindowl&NewWindow); 

55: 

56: if (Window == NULL) 

57: { 

58: CloseLibrary(GfxBase); 

59: CloseLibrary(IntuitionBase); 

60: exit(FALSE); 

61: } 

62: 

63: /* Rastport beschaffen und Text ausgeben: */ 

64: rp = Window->RPort; /* Der Rastport */ 

65: SetAPen(rp, 1L); /* Farbe weiß */ 

66: Move(rp, 100, 50); /* Cursor -> x,y */ 

67: Textfrp, "Hallo Welt!“,11L); /* Text zeichnen */ 

68 : 

69: /* Auf Message warten, 

70: kann hier hier nur Close sein: */ 

71: Wait(lL « Window->UserPort->mp_SigBit); 

72: 

73: CloseWindow(Window); /* Alles schließen */ 

74: CloseLibrary(GfxBase); 

75: CloseLibrary(IntuitionBase); 

76: 

77: exit(TRUE); /* und Ende */ 

78: } © 1993 M&T 

Listing 1: Ein simples Intuition-Programm, das ein 
Fenster öffnet und »Hallo Welt!« hineinschreibt 
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»DispatchMessageO« an die Funktion »Wnd- 
Proc()« gesendet. 

Da fragt man sich zunächst, warum ausge¬ 
rechnet dorthin? Die schlichte Antwort: Weil 
Sie beim Registrieren der Klasse den Zeiger 
auf diese Funktion in die Klassenstruktur ein¬ 
getragen haben. 

Also geht’s jetzt bei »WndProcO« weiter. 
Die MSG-(Message-) Struktur an sich ent¬ 
spricht ziemlich genau der von Intuition 
inklusive Uhrzeit und Mauskoordinaten. 
»DispatchMessageO« löst diese Struktur 
jedoch auf und sendet nur noch den Typ und 
zwei Parameter (entspricht der Message- 
Klasse und dem Code in zwei Gruppen). 
Auch WndProcO ist eine Callback-Funktion, 


wird also nur von Windows aufgerufen, doch 
hier steht auch der Kern Ihres Programms. In 
diesem einfachen Beispiel sind die Händler 
für die beiden Messages »WM_PAINT« und 
»WM_CLOSE« direkt in den Switch-Selek¬ 
tor geschrieben worden - normalerweise wird 
man hier jedoch Funktionsaufrufe einsetzen. 

Der wichtigste Fall ist »WM_PAINT«. 
Diese Message wird immer dann gesendet, 
wenn ein Fenster neu zu zeichnen ist, also 
zuerst nach dem Start, nach jedem Verschie¬ 
ben, nach jeder Größenänderung und in noch 
einigen Fällen. Was genau anliegt, finden wir 
in der »PAINTSTRUCT«-Struktur, z.B. das 
Rechteck, das zu aktualisieren ist. Die Struk¬ 
tur wird an »BeginPaintO« übergeben, womit 


weitere Änderungen gesperrt werden. Ist das 
Fenster neu gezeichnet, gibt man es mit 
»EndPaintO« wieder frei. 

Als nächste Message wertet man 
»WM_CLOSE« aus. Man beachte den feinen 
Unterschied zu Intuition: »DestroyWin- 
dow()« löscht das Fenster der aktuellen 
Instanz. Anschließend prüft man, ob das die 
letzte (oder einzige) Instanz war. Nur in die¬ 
sem Fall wird mit »PostQuitMessage(O)« die 
Ende-Nachricht in den Message-Queue 
gepackt. 

Wie gesagt, »WndProcO« wird von »Win- 
Main()« aufgerufen, also geben wir die Kon¬ 
trolle dorthin zurück. Hier findet die Mes- 
sage-Loop die Null- oder Quit-Message vor 


1 

#include <windows.h> 

87 


2 

üinclude <string.h> 

88 

LONG FAR PASCAL WndProc(HWND hWnd, WORD Message, 

3 


89 

WORD wParam, LONG lParam) 

4 

char szAppName[20]; // Klassen-Name für dieses Window 

90 

{ 

5 

HWND hlnst; // Instanz-Handle 

91 

HDC hDC; // Handle für Display-Device-Context 

6 

HWND hWndMain; // Window-Handle 

92 

PAINTSTRUCT ps; // Hält PAINT-Informationen 

7 


93 

int nRc=0; // Return-Code 

8 

// Prototypen (siehe unten) 

94 


9 

LONG FAR PASCAL WndProc(HWND, WORD, WORD, LONG); 

95 

switch (Message) 

10 

int nCwRegisterClasses(void); 

96 

{ 

11 

void CwUnRegisterClasses(void) ,* 

97 

case WM PAINT: // Neuzeichnen evtl, nötig 

12 


98 

memset(&ps, 0x00, sizeof(PAINTSTRUCT)); 

13 


99 

hDC = BeginPaint(hWnd, &ps); // Melde Start 

14 

int PASCAL WinMain(HANDLE hlnstance, HANDLE hPrevInstance, 

100 

SetBkMode(hDC, TRANSPARENT); // Hintergrund löschen 

15 

LPSTR IpszCmdLine, int nCmdShow) 

101 

TextOut(hDC, 20, 20, "Hallo Welt!", 11); 

16 

{ 

102 

EndPaint(hWnd, &ps); // Melde, daß Painting fertig 

17 

/fr************************************************** 

103 

break; 

18 

* Hier startet das Programm. * 

104 


19 

* Diese Funktion wird nur von Windows aufgerufen! * 

105 

case WM CLOSE: // User schließt Window 

20 

*************★*********★**★*+*★****++********★*****/ 

106 

DestroyWindow(hWnd); // Window abbauen. 

21 


107 

if (hWnd == hWndMain) // Wenn es das letzte ist, 

22 

MSG msg; // Message-Struktur 

108 

PostQuitMessage(O); // Ende melden 

23 

int nRc; // Return-Wert von RegisterClasses 

1CT9 

break; 

24 


110 


25 

s t rcpy(s zAppName, "Demo"); 

111 

default: 

26 

hlnst = hlnstance; 

112 

// Für alle Messages, die keine Service-Routine haben, 

27 

if(!hPrevInstance) 

113 

// Messages an Windows für Default-Prozess zurück: 

28 

( 

114 

retum DefWindowProc(hWnd, Message, wParam, lParam); 

29 

// Wenn es die erste Instanz ist, Klasse registrieren 

115 

} 

30 

if ((nRc = nCwRegisterClasses()) == -1) 

116 

return 0L; 

31 

{ 

117 

} // End of WndProc 

32 

// Wenn Fehler beim Registrieren 

118 


33 

MessageBox(NULL, 'Konnte Klase nicht registrieren", • 

119 

/****************★******************************** 

34 

"Sorry", MB_ICONEXCLAMATION); 

120 

* * 

35 

retum nRc; 

121 

* Generelle Funktion. * 

36 

} 

122 

★ * 

37 

} 

123 

* Registriert alle Klassen aller Windows, * 

38 


124 

* die zur Applikation gehören. * 

39 

// Klasse gibt es, also Window anlegen: 

125 

* Retum: 0, wenn erfolgreich, sonst Error-Code * 

40 

hWndMain = CreateWindow( 

126 

* * 

41 

szAppName, // Name der Applikation 

127 


42 

"Text des Titels", // Das sog. Caption 

128 


43 

WS_CAPTION 1 //Hat Titeileiste und 

129 

int nCwRegisterClasses(void) 

44 

WS_SYSMENU 1 // System-Menü und 

130 

{ 

45 

WS_MINIMIZEBOX 1 // Minimum-Box und 

131 

WNDCLASS wndclass; // Struct der Windowsklasse 

46 

WS_MAXIMIZEBOX 1 // Maximum-Box und 

132 

memset(&wndclass, 0x00, sizeof(WNDCLASS)); 

47 

WS_THICKFRAME I // Malt nicht in Child-Windows 

133 


48 

WS.OVERLAPPED, // Kann überlappen 

134 


49 

CW_USEDEFAULT, 0, // Default für links oben 

135 

// Stuktur laden: 

50 

CW.USEDEFAULT, 0, // Default für rechts unten 

136 

wndclass.Style = CS_HREDRAW 1 CS_VREDRAW 1 CS_BYTEALIGNWINDOW; 

51 

NULL, // Ist keine MDI-Applikation 

137 

wndclass.lpfnWndProc = WndProc; 

52 

NULL, // Default ist Klassen-Menü 

138 

// Kein Extra-Storage für Klassen- und Windows-Objekte: 

53 

hlnst, // Instanz dieses Windows 

139 

wndclass.cbClsExtra = 0; 

54 

NULL); // Kein Struct für WM_CREATE 

140 

wndclass.cbWndExtra = 0; 

55 


141 

wndclass.hlnstance = hlnst; 

56 


142 

wndclass.hlcon = Loadicon(NULL, IDI_APPLICATION); 

57 

if(hWndMain == NULL) 

143 

wndclass.hCursor = LoadCursor(NULL, IDC_ARROW); 

58 

{ 

144 

// Brush für Hintergrund-Löschen anlegen: 

59 

MessageBox(NULL, "Konnte Window nicht anlegen", 

145 

wndclass.hbrBackground = (HBRUSH)(COLOR_WINDOW+l); 

60 

"Sorry", MB_ICONEXCLAMATION); 

146 

wndclass.IpszMenuName = szAppName; // Menü-Name = App.-Name 

61 

retum 1; 

147 

wndclass.IpszCIassName = szAppName; // Klassen-Name = App.-Name 

62 

> 

148 


63 


149 

return RegisterClass(&wndclass); // Registrieren 

64 

ShowWindow(hWndMain, nCmdShow); // Window anzeigen 

150 

) // End of nCwRegisterClasses 

65 


151 


66 

while(GetMessage(&msg, NULL, 0, 0)) // Endlos 

152 

/ft******************************************* 

67 

{ 

153 

* CwUnRegisterClasses-Funktion * 

68 

TranslateMessage(&msg); // Keys übersetzen 

154 

★ * 

69 

DispatchMessage(&msg); // Message an WndProc 

155 

* Löscht alle Refrenzen zu den Resourcen * 

70 


156 

* und alle Handles und gibt Speicher frei.* 

71 

} // bis WM_Quit-Message 

157 

*********★*★★*★★★★★*★*★*★************★*★★***/ 

72 


158 


73 

// Rückzugsgefechte und Ende 

159 

void CwünRegisterClasses(void) 

74 

CwünRegisterClasses(); 

160 

{ 

75 

retum msg.wParam; 

161 

WNDCLASS wndclass; 

76 

} // End of WinMain 

162 

memset(&wndclass, 0x00, sizeof(WNDCLASS)); 

77 


163 


78 


164 

UnregisterClass(szAppName, hlnst); 

79 

/******************************************«**** 

165 

} 

80 

* * 
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81 

82 

83 

* WndProc (Main Window Procedure) * 



* Hierher sendet Windows Messages über alle * 



84 

* Events, egal ob das User-Aktionen sind oder * 

Listing 2: Das Windows-Pendant zu Listing 1 ist nicht nur 

85 

86 

* Windows-Messages. * 

fr**********************************************/ 

wegen der ausführlicheren Kommentare länger 
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und endet. Das Programm setzt bei »cwUn- 
RegisterClassesO« fort - wir finden die 
Funktion am Listingende. Hier wird nur die 
Klasse und damit der gesamte Speicher der 
Applikation freigegeben, in der Praxis Finden 
hier noch ein paar weitere »Rückzugsge¬ 
fechte« statt. 

Sehr gute Entwicklungssysteme 

Nach den ersten Grundlagen nun etwas zur 
Umgebung, in der Windows-Programme ent¬ 
wickelt werden. Sie können in »Visual 
Basic« (herrlich einfach), in C, C++ oder in 
Pascal arbeiten. In allen Fällen ist es dem 
Programm nicht anzusehen, welcher Compi¬ 
ler es erzeugt hat, da alle Entwicklungssy¬ 
steme auf dasselbe Windows-API zugreifen. 
Dieses »API« ist mit über 600 Funktionen 
deutlich leistungsfähiger als das von Intui¬ 
tion, und wird noch durch einige DLLs, z.B. 
für alle Standarddialoge, ergänzt. Hier liegt 
allerdings auch die Hürde, denn die 600 
Funktionen plus Hunderte von Messages muß 
man erst einmal kennen. 

Am schnellsten kommt man mit Windows 
in der Programmiersprache C klar, denn das 
ist (wie bei Intuition) seine Muttersprache. 
Die gesamte Dokumentation des »SDK« 
(Software Development Kit) von Microsoft - 
es sind ja nur 5000 Seiten - basiert auf C. 
Sofern Sie nicht schon sehr fit in C++ sind, 
sollten Sie mit C starten, und zwar am ein¬ 
fachsten mit »Quick C« für Windows. Bild 2 
demonstriert, daß dessen Entwicklungsumge¬ 
bung selbst eine Windows-Applikation ist, 
weshalb Sie, ohne die Umgebung verlassen 
zu müssen, Programme sofort austesten und 
debuggen können. Zu »QCAVin« gehört auch 


womit wir beim nächsten Unterschied wären: 
In Windows gibt es eine ganz klare Trennung 
zwischen Code und Ressourcen - jedenfalls 
sollte es so sein. In Listing 2 sind sämtliche 
Stringliterale, also die Texte für Message- 
Boxen oder das »"Hallo Welt"«, bereits ein 
grober Verstoß gegen die Spielregeln. Nor¬ 
malerweise programmiert man nicht so, doch 
das Listing sollte im ersten Ansatz nicht allzu 
kompliziert sein. Ressourcen sind alle Texte, 
die das Programm ausgibt, die Menüs, alle 
Dialoge, der Cursor bzw. der Mauszeiger, 
jeder Zeichensatz, jedes Bild: Kurz gesagt 
alles, was man sieht, mit Ausnahme der Fen¬ 
ster. 

Die Ressourcen erzeugt man mit getrenn¬ 
ten Tools, übersetzt sie mit einem Ressource- 
Compiler und bindet sie schließlich mit dem 
Programmcode zu einer ausführbaren Datei 
(».EXE«). Das ist auch der Grund, weshalb 
man ein US-Programm eindeutschen kann, 
ohne den Quelltext besitzen zu müssen. Spe¬ 
zielle Ressourceeditoren ziehen den Ressour¬ 
centeil aus der Exe-Datei heraus, wandeln ihn 
in Bilder oder Klartext um, erlauben das Edi¬ 
tieren, Kompilieren und Linken. Zu empfeh¬ 
len ist der »Resource Workshop« von Bor¬ 
land. 

Auch die grafischen Tools erzeugen im 
Falle von Menüs, Strings und Dialogen Text¬ 
dateien. Früher gab es die Editoren nicht, da 
tippte jeder die Text- und Header-Dateien 
selbst. Heutzutage editiert man nur bei klei¬ 
neren Änderungen, z.B. einem neuen Menü¬ 
punkt, die Textdateien direkt. 

Um den Unterschied im Umgang mit 
Menüs und Messages zu verdeutlichen, zeigt 
Listing 3 die Message-Loop und den Menü- 


In Listing 4 - einem Auszug aus einem 
Texteditor - geht's nun los. Nachdem ein 
Menü aufgebaut oder eingeschaltet ist, sendet 
Windows eine »WM_INITMENU«-Message. 
Hier wird geprüft, ob Text in der Zwi¬ 
schenablage ist und wenn ja, der Menüpunkt 
»Einfügen« (Paste) aktiviert, andernfalls wird 
er grau gezeichnet (MF_GRAYED). Übri- 
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Bild 4: Dialogboxen sind sehr viel ein¬ 
facher anzulegen und zu handhaben 
als die Requester von Intuition älterer 
Betriebssysteme. OS 2.0 hat aufgeholt. 

gens stammen diese und andere Konstanten 
sowie alle Prototypen aus der rund 140 
KByte großen Headerdatei »Windows.h«. Die 
Punkte »Neu«, »Öffnen« und »Sichern« 
schreibt man auf dem Amiga sinngemäß, nur 
daß man hier die Standarddialoge aus 
»CmnDlg.DLL« einsetzen sollte. Diese Dia¬ 
loge folgen der alten Regel »Struktur laden, 
Funktion aufrufen«. Recht kompliziert hinge¬ 
gen ist das Drucken. Da es lange dauern 
kann, bis die Grafik einer Seite aufgebaut ist 


1 

for(;;) /* Message-Loop */ 

19 

do_jnenu (); 

40 

break; 

2 

{ 

20 

break; 

41 


3 

Wait(lL « Window->üserPort-> 

21 

) 

42 

case IDM_BEARBEITEN: 


mp_SigBit); 

22 

} 

43 

switch(ITEMNUM(code)) 

4 


23 

} 

44 

( 

5 

while( msg = GetMsg(Window->UserPort) 

24 


45 

case IDM_B_UNDO: 

) 


25 


46 

do_Undo(); 

6 

{ 

26 

void do_menu() 

47 

break; 

7 

dass = msg->Class; 

27 

{ 

48 

case IDM_B_COPY: 

8 

code = msg->Code; 

28 

switch(MENUNUM(code)) /* Switch Titel */ 

49 

do_Copy(); 

9 

ReplyMsg( msg ); 

29 

{ 

50 

break; 

10 


30 

case IDM_DATEI: 

51 

} 

u 

switch( dass) 

31 

switch(ITEMNUM(code)) 

52 

break; 

12 

{ 

32 

{ 

53 

} 

13 

case CLOSEWINDOW: 

33 

case IDM_D_NEU: 

54 

} 

14 

close_all(); 

34 

Do_Neu(); 
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15 

break; 

35 

break; 



16 


36 

case IDM_D_OEFFNEN: 



17 

18 

case MENUPICK: 

if (MENUNUM (code) != 

37 

38 

Do_Oeffnen(); 
break; 

Listing 3: Die Message-Loop und der 


MENUNULL) 

39 

) 

Menü-Handler sehen unter Intuition 


ein CASE-Tool, mit dem sich die gesamte 
Bedieneroberfläche eines Programms, also 
Menüs und Dialoge, mit der Maus zusam¬ 
menstellen lassen. Bild 3 zeigt, wie auf diese 
Art Menüs entstehen und Bild 4 ist ein 
Schnappschuß des Dialogeditors. Ein Image¬ 
editor für Bildchen oder eigene Mauszeiger 
gehört noch dazu. 

Code und Ressourcen strikt trennen 

Das Ergebnis des CASE-Tools ist C-Quell- 
text plus einem Make-File, der die zusätzlich 
erzeugten Quelltexte dem Compiler anbietet, 


Händler von Intuition und Listing 4 das Win¬ 
dows-Pendant. Letzteres ist jetzt aber nur län¬ 
ger, um bei der Gelegenheit noch eine Diffe¬ 
renz zu nennen. 

Zuerst sollte auffallen, daß man sich unter 
Intuition via »MENUPICK«, »MENU- 
NUM«, »ITEMNUM« usw. zu dem einzel¬ 
nen Menüpunkt Vorarbeiten muß, während in 
Windows jeder Menüpunkt direkt angespro¬ 
chen wird. Die Hierarchie verwaltet Win¬ 
dows selbst, was z.B. zur Folge hat, daß alle 
Items eines Menüs »disabled« sind, blendet 
man den Titel aus. 


(auch Text ist nur Grafik), ist für die unge¬ 
duldigen Benutzer zunächst ein Abbruchdia¬ 
log (-Requester) zu laden, einzubinden und 
bei Windows anzumelden. Dann muß man 
sich die Auflösung einer Druckerseite 
beschaffen, für jede Zeile die maximale Höhe 
ermitteln und so zu einer Zeilenzahl pro Seite 
kommen. Daß man noch einen kompatiblen 
DC anlegen muß, um gemäß der Duckerauf¬ 
lösung das Bild im Speicher aufbauen zu 
können, sich bei Bildern um eine kompatible 
Bitmap kümmern und sich auch noch Spei¬ 
cher beschaffen muß, sei nur am Rande 
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INTERN 


erwähnt. Der nächste Punkt, nämlich die 
Druckerinstallation, verdeutlicht noch ein¬ 
mal, was hier alles zu berücksichtigen ist. 

Das Problem: Der Druckerinstallations¬ 
oder Einrichten-Dialog (Auflösungswahl, 
Rändereinstellung, Anzahl Kopien u.ä.) 
gehört nicht zum Windows-API, sondern 
wird vom Druckerhersteller als Teil des Trei¬ 
bers geliefert. Übrigens ist ein Treiber 
(»*.DRV«) auch nur eine DLL. Welche 
Drucker der Anwender installiert hat und 
welcher aktiv ist, finden wir in der Textdatei 
»WIN.INI«, die Windows bei jedem Start 
interpretiert und ausführt, die sich aber auch 
zur Laufzeit aktualisieren läßt. Mittels einer 
Windows-Funktion sucht und lädt man diese 
Zeile, zerlegt sie in ihre drei Worte, hängt (an 
ein Wort) das noch fehlende ».DRV« an und 
lädt dann die DLL. Mit einer weiteren Win¬ 
dows-Funktion »GetProcAddressO« läßt sich 
die Dialogfunkion im Treiber finden, wobei 
unterstellt wird, daß der Druckerhersteller 
vereinbarungsgemäß deren Einsprung »Devi- 
ceMode« oder »ExtDeviceMode« (es gibt 
manchmal zwei Dialoge) genannt hat. Das 
Ergebnis aller Mühen ist ein Zeiger auf die 
Dialogfunktion. Diese Funktion wird mit 
einer Struktur und noch einigen Argumenten 
aufgerufen. Wenn der Anwender den Dialog 
schließt, kann man seine Wahl in der Struktur 
ablesen. 

Der Menüpunkt »Info« zeigt, wie ein Dia¬ 
log aufgerufen wird. Das Problem dabei: Die 
Dialogfunktion ist eine Callback-Funktion. In 
unserem Fall heißt das, daß der Dialog voll 


von Windows verwaltet wird. Nun soll aber 
die Menüanwahl diesen Dialog auf den 
Schirm bringen. Deshalb wird mit »Make- 
Proclnstance« eine Dialog-Instanz gebildet 
und dabei die Adresse der Dialogfunktion 
ermittelt. Damit und mit dem Ressource- 
Namen des Dialogs wird »DialogBoxO« auf¬ 
gerufen. Nun ist der Dialog auf dem Schirm 
und die Funktion »AboutO« arbeitet. Vor 
dem Aufbau sendet Windows eine 
»WM_INITDIALOG«-Message, was hier 
genutzt wird, um den Dialog zu zentrieren. 
Ansonsten kann man wieder diverse Messa¬ 
ges abfragen. Es wird nur geprüft, ob der 
User den OK-Schalter anklickt oder <Esc> 
drückt, was den Dialog beendet. Der Aufru¬ 
fer kann die in globalen Variablen übermit¬ 
telten Ergebnisse auswerten, um dann mit 
»FreeProcInstanceO« die Instanz freizugeben. 

Alle Menüpunkte des Bearbeiten-Menüs 
zeigen ein interessantes Feature von Win¬ 
dows auf. Ein kompletter Editor mit Mausbe¬ 
dienung, Rollbalken und dem ganzen Service 
der Zwischenablage ist nämlich in Windows 
schon eingebaut. Deshalb senden alle Menü- 
Handler nur Kommandos an Windows. Das 
ist übrigens typisch. Nachdem ein Fenster 
angelegt wurde, hat man nur noch sein 
Handle. Will man dann etwas von dem Fen¬ 
ster, greift man in der Regel nicht auf die 
Struktur zu, sondern verschickt Messages 
oder ruft spezielle Funktionen auf. Via 
»EnumPropO« kann man zwar auch auf die 
Eigenschaften (Properties) eines Fensters 
zugreifen, doch darf (sollte) man dann nur 


Properties ändern oder löschen, die man vor¬ 
her selbst hinzugefügt hatte. 

Ganz nett ist auch die Message 
»WM.QUERYENDSESSION«. Diese sen¬ 
det Windows an alle Tasks, wenn der 
Anwender Windows verlassen möchte. Jeder 
Task sollte dann seine Endrunde drehen und 
schließlich »TRUE« zurückgeben. Tut ein 
Programm das nicht, ist es nicht möglich, 
Windows zu verlassen. 

Die weiteren Messages machen klar, was 
noch zu tun ist. So etwa sollte ein Editor- 
Window nach einer »WM_SETFOCUS«- 
Message (das Fenster wurde aktiviert) den 
Caret-Cursor (das Schreibmarkensymbol) 
setzen. Wichtig ist jedoch in dieser Applika¬ 
tion, auf Größenänderungen des Fensters 
(WM_SIZE) zu reagieren. Hier trifft man 
auch den relativ häufigen Fall an, daß in 
»lParam« (einem Langwort) zwei Daten in 
den beiden Wörtern stehen. »lParam« wird 
aber auch sehr häufig ein Zeiger sein. 

Bleibt als Fazit, daß die Kunst der Win¬ 
dows-Programmierung darin liegt, von über 
600 Funktionen und Hunderten von Messa¬ 
ges die richtigen zum richtigen Zeitpunkt ein¬ 
zusetzen. Alles, was mit der Oberfläche zu 
tun hat, lösen CASE-Tools und Ressource- 
Editoren fast automatisch. 

Alle Listings finden Sie auch auf unserer 
Diskette zum Heft (Seite 114). Selbstver¬ 
ständlich sind die Windows-Programme nicht 
mit den gängigen Amiga-C-Compilern zu 
übersetzen. Da muß schon Windows und ein 
entsprechendes Tool her. rz 


1 

2 

switch (Message) 

53 

break; 

3 


55 

case IDM_D_DRUCKEN : 

4 

case WM_INITMENU: // Wenn Menü aufgebaut wird: 

56 

// Teste, ob Drucker verfügbar 

5 

// Nicht verfügbare Menüs abblenden, z.B. "Paste“, 

57 

hPr = GetPrinterDCO; 

6 

// wenn kein Text in der Zwischenablage steht. 

58 

if (!hPr) 

7 

if(OpenClipboard(hEditWnd)) 

59 

{ /* Meldung und Abbruch*/ ) 

8 

{ 

60 

// Definniere Abort-Dialog. 

9 

if(IsClipboardFormatAvailable(CF_TEXT)) 

61 

// Beschaffe Auflösung einer Druckerseite 

10 

EnableMenuItem(wParam, IDM_B_PASTE, MF_ENABLED); 

62 

// und Zeilenhöhe. Rechne Anzahl Zeilen/Seite. 

11 

eise 

63 

// Lege kompatiblen DC an. 

12 

EnableMenuItem(wParam, IDM_B_PASTE, MF_GRAYED); 

64 

// Drucke via TextOut(). 

13 

CloseClipboard(); 

65 

// Letzte Seit vorschieben und Ende 

14 

) 

66 

// Abort-Dialog abbauen 

15 

break; 

67 

// Speicher freigeben 

16 


68 

break; 

17 

case WM_COMMAND: // Window-Kommando 

69 


18 


70 

case IDM_D_DRUCKERINSTALLATION: 

19 

switch (wParam) // Bearbeite Menüs 

71 

/* Beschaffe Druckerkontext. Funktion 

20 

{ 

72 

ermittelt auch Druckerdaten. 

21 

case IDM_D_NEU: // Neue Datei 

73 

*/ 

22 

/* Wenn vorherige Datei ungesichert. 

74 

II Lade Druckertreiber (Name in WIN.INI) 

23 

Frage ob sichern. V 

75 

I* Ermittle Zeiger auf Druckerinst.-Funktion 

24 

if (IQuerySaveFile(hWnd)) 

76 

und rufe sie auf *1 

25 

retum (NULL) ; 

77 

lpfnDevmode = GetProcAddress(hLibrary, 

26 

bChanges = FALSE; // Nichts geändert 

78 

"EXTDEVICEMODE"); 

27 

FileName(0] =0; // Kein File-Name 

79 

nResult = (*lpfnDevmode) (hWnd, hLibrary, 

28 

// Lege neuen Edit-Puffer an: 

80 

&devmode, 

29 

SetNewBuffer(hWnd, NULL, Untitled); 

81 

(LPSTR) szDevice, 

30 

break; 

82 

(LPSTR) szOutput, 

31 


83 

NULL, NULL, 

32 

case IDM_D_OEFFNEN : 

84 

DM_COPY 1 DM_PROMPT); 

33 

// Teste, ob aktuelle Datei gesichert 

85 

break; 

34 

if (!QuerySaveFile(hWnd)) 

86 


35 

return (NULL); 

87 

case IDM_D_INFO: // Zeige About-Dialog 

36 

// Zeige Standard-Dialog, bewerte User-Wahl, 

88 

lpfnProcAbout = MakeProcInstance(About, hlnst); 

37 

// lese Datei ein. 

89 

DialogBox(hInst, "AboutBox", hWnd, 

38 

break; 

90 

lpfnProcAbout); 

39 


91 

FreeProcInstance(lpfnProcAbout); 

40 

case IDM_D_SICHERN : 

92 

break; 

41 

// Wenn Filename leer, gehe zu "Sichern unter" 

93 


42 

if (!FileName[0]) 

94 


43 

goto saveas; 

95 

case IDM_D_BEENDEN : 

44 

// Wenn File geändert, Speicher ihn 

96 

QuerySaveFile(hWndMain); 

45 

if (bChanges) 

97 

PostMessage(hWnd, WM_CLOSE, 0,0); 

46 

SaveFile(hWnd) ; 

98 

break; 

47 

break; 

99 


48 


100 

// Das ganze Bearbeiten-Menü eines Editors 

49 

case IDM_D_SICHERNUNTER : 

101 

// kann Windows erledigen 

50 

saveas: // Zeige Standard-Dialog, bewerte User-Wahl, 

102 

case IDM_3_UNDO: 

51 

// lese Datei ein. 

103 

SendMessage(hEditWnd, WM_UNDO, 0, 0L);. 

52 

SaveFile(hWnd); 

104 

break; 
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105 


155 

// Setze Caret-Cursor 

106 

case IDM_B_COPY: 

156 

break; 

107 

SendMessage(hEditWnd, WM_COPY, 0, 0L); 

157 


108 

break; 

158 

case WM_SIZE: // Größe neu 

109 


159 

//in lParam steht neue Width u. Height 

110 

case IDM_B_CUT: 

160 

MoveWindow(hEditWnd, 0, 0, LOWORD(lParam), 

111 

SendMessage(hEditWnd, WM_CUT, 0, 0L); 

161 

HIWORD(lParam), TRUE); 

112 

break; 

162 

break; 

113 


163 


114 

case IDM_B_PASTE: 

164 

case WM_PAINT: 

115 

SendMessage(hEditWnd, WM_PASTE, 0, 0L); 

165 

// Clear Background 

116 

break; 

166 

memset(&ps, 0x00, sizeof(PAINTSTRUCT)); 

117 


167 

hDC = BeginPaint(hWnd, &ps); 

118 

case IDM_B_ALL: 

168 

SetBkMode(hDC, TRANSPARENT); 

119 

SendMessage(hEditWnd, EM.SETSEL, 0, 

169 

EndPaint(hWnd, &ps); 

120 

MAKELONG(0, 32767)); 

170 

break; 

121 

break; 

171 


122 


172 

case WM_CLOSE: 

123 

case IDM_B_CLEAR: 

173 

DestroyWindow(hWnd); 

124 

SendMessage(hEditWnd, WM_CLEAR, 0, 0L); 

174 

if (hWnd == hWndMain) 

125 

break; 

175 

PostQuitMessage(0); 

126 


176 

break; 

127 

case IDM_B_DEL: 

177 


128 

OpenClipboard(hEditWnd); 

178 

default: 

129 

EmptyClipboard(); 

179 

return DefWindowProc(hWnd, Message, wParam, lParam); 

130 

CloseClipboardO ; 

180 

} 

131 

break; 

181 


132 


182 


133 

case IDM_B_FIND: 

183 


134 

II Lauft via Standard-Dialog 

184: BOOL FAR PASCAL About(HWND hDlg, WORD Message, 

135 

break; 

185: WORD wParam, LONG lParam) 

136 


186 

{ 

137 


187 

switch (Message) { 

138 

case IDM_B_REPLACE: 

188 

case WM_INITDIALOG: 

139 

// Lauft via Standard-Dialog 

189 

cwCenter(hDlg, 0); 

140 

break; 

190 

return TRUE; 

141 

default : 

191 


142 

return DefWindowProc(hWnd, Message, 

192 

case WM_COMMAND: 

143 

wParam, lParam) ; 

193 

if (wParam == IDOK |! wParam == IDCANCEL) 

144 


194 

return EndDialog(hDlg, TRUE); 

145 

} // End of switch wParam 

195 

break; 

146 


196 

} 

147 


197 

return FALSE; 

148 

/•/ Weitere Windows-Messages 

198 

} 

149 

case WM_QUERYENDSESSION: 

199 


150 

/* Wenn Windows beendet wird und 
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151 

ein File ungesichert, Frage ob OK. */ 



152 

153 

return (QuerySaveFile(hWnd)) ; 

Listing 4: Die berühmte Switch-Orgie zum Message-Hand¬ 

154 

case WM_SETFOCUS: // Window hat Fokus erhalten 

ling in einem Windows-Programm sieht man noch häufig 



Wenn Sie sich schon immer geärgert haben, 
daß... 


★ Ihre Programme so langsam sind (Basic), 

★ Sie Ihre Programme nicht lesen können ("C"), 

★ Ihre Programme nicht laufen (Assembler), 

★ Sie Ihre Programme nicht verstehen (Lisp), 

★ Ihre Programme so mittelalterlich sind (Fortran), 

★ Ihre Programme erst posthum terminieren (Prolog), 

★ Sie auf alles verzichten, nur damit Ihre Programme 
auf allen Rechnern laufen (Modula2), 

★ Ihre Sprache nicht hält, was der Name verspricht 
(Oberon), 

★ Sie immer noch keine Zeile geschrieben haben (Ada), 

und vor allem, daß Programmiersprachen so schwer zu be¬ 
nutzen sind, dann sollten Sie sich Cluster zulegen. 

Cluster ist eine Erweiterung zu 
Modula-2, kann aber auch original 
Modula übersetzen. Sie zeichnet 
sich besonders durch hohe 
Lesbarkeit, schnellen Code sowie 
komfortable Bedienung aus. 
Besonders hervorzuheben sind 
dabei die objektorientierten 
Elemente von Cluster (Mehrfacherben, Late-Binding) sowie 
sein Exception- und Recourcehandling. 


Integriertes 

Software-Entwickler-System 


CLUSTER 

enthält eine völlig frei konfigurierbare und 
AREXX-programmierbare Entwicklungs¬ 
umgebung. Dazu gehören ein schneller 
OS-2.0-Style Editor sowie ein über 
AREXX ansteuerbarer Compiler, Linker, 
Loader und Make. Alle Funktionen können 
dabei komfortabel aus dem Editor heraus 
bedient werden. Dadurch und durch einen 
sehr schnellen Compiler werden Entwick¬ 
lungszeiten stark verkürzt. 

CLUSTER 

meldet Laufzeitfehler mit Quelltextzeilen¬ 
angabe und verursacht keine Abstürze. 

o». 


ist vollständig Kickstart-2.0-kompatibel 
und unterstützt die neuen Bildschirm¬ 
auflösungen. 

CLUSTER 

erzeugt sowohl optimierten Code für den 
MC68000 als auch für den 
MC 68020/30/40 und MC 68881/2. 


Überzeugen Sie sich selbst: 

Eine Demo-Diskette erhalten Sie bei 


Ein Beweis für 
die Leistungs¬ 
fähigkeit von 
Cluster: 

Das EGS-Betriebssystem der Visiona- 
Grafikkarte, der GVP IV-24-Grafik- 
karte und der neuen GVP Grafikkarte 
ist komplett in Cluster geschrieben. 


DTM 

COMPUTERSYSTEME 


Dreiherrenstein 6a Tel. 06127 4064 

6200 Wiesbaden-Auringen Fax 06127 66276 
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Profitips von Programmierern 

Effiziente Assembler- 
Programmierung 


Assembler ist heute eine weit ver¬ 
breitete Technik, Programme für 
den Amiga zu entwickeln. Fast 
alle Spiele werden in Assembler 
geschrieben, da nur so höchste 
Geschwindigkeit und kurze, präg¬ 
nante Algorithmen mit optimaler 
Ausnutzung des Prozessors mög¬ 
lich sind. Hier bekommen Sie 
Informationen aus erster Hand - 
vom Entwickler des schnellen 
OMA-Assemblers. 

von Dietmar Heidrich 

D ie Assembler-Programmierung erlebt 
auf dem Amiga ihren zweiten Früh¬ 
ling. Sie ist zwar nicht so bequem wie 
Hochsprachen, erlaubt jedoch optimale Aus¬ 
nutzung der Prozessorleistung. Selbst größere 
Projekte wie z.B. der optimierende Makro- 
Assembler »OMA« wurde in Assembler 
implementiert. 

Allerdings handelt man sich bei der 
Assembler-Programmierung eine Reihe 
Nachteile ein. Die Entwicklungszeit für 
Assembler-Programme liegt etwa um den 
Faktor fünf höher als die der Hochsprachen¬ 
programmierer. Fehler treten viel häufiger 
auf, da sie sich meist erst zur Laufzeit 
bemerkbar machen und in den wenigsten Fäl¬ 
len schon vom Assembler gefunden werden 
können. Typprüfungen Finden z.B. überhaupt 
nicht statt. Ein beliebter Fehler ist auch das 
Überschreiben eines Registerinhalts in Unter¬ 
routinen (sog. Seiteneffekte). 

Im allgemeinen neigen Assembler-Pro¬ 
grammierer dazu, die Zeit für Optimierungen 
zu verschwenden, die die Gesamtlaufzeit fast 
gar nicht beeinflussen. Was kann man also 
tun, um die Assembler-Programmierung zu 
erleichtern, einfacher und vor allem weniger 
fehleranfällig zu machen? 

Der erste Punkt ist die Verwendung sym¬ 
bolischer Namen. Ein Assembler interpretiert 
Werte nicht nur als Zahl, sondern auch als 
Symbol. Sicherlich ist 
move.l gg_SpecialInfo(aO),a0 
leichter verständlich als 
move.l $22(aO),aO 


Zudem erübrigt sich im ersten Fall ein 
Kommentar. Wirft man einen kritischen 
Blick auf die in Zeitschriften veröffentlichten 
Listings, fällt auf, daß im Quelltextanfang 
immer wieder Konstanten des Amiga- 
Betriebssystemes definiert werden. Tut man 
das nicht - der Fehlerteufel läßt grüßen. Alle 
gängigen Assembler ermöglichen es, mit 
Hilfe der INCLUDE-Direktive Include- 
Dateien zu lesen, in denen wichtige Konstan¬ 
ten vereinbart werden. Das ist auch für die 
Programmierer interessant, die direkt die 
Hardware adressieren: symbolische Bezeich¬ 
ner für die Custom-Chips sind in den Inclu- 
des vorhanden und lassen sich auch hier ver¬ 
wenden. Beispielsweise kann man das Blt- 
Size-Register so ansprechen: 
move dO,_custom+bltsize 

Der Aufruf von Betriebssystemroutinen ist 
ein weiterer Punkt. Obwohl die Include-Datei 
»exec/libraries.i« die »CALLLIB«- und 
»LINKLIB«-Makros bietet und weitere in der 
2.0-Include-Datei »exec/macros.i« definiert 
wurden, bieten diese keinen besonderen 
Komfort, denn der Library-Offset der 
Systemroutine wird immer noch aus der 
»amiga.lib« abgeleitet. Der OMA-Assembler 
V2.05 enthält Include-Dateien fürs Betriebs¬ 
system 2.0 und 1.3, in denen die Offsets aller 
Betriebssystemroutinen definiert sind. Damit 
erübrigt sich das Linken mit der »amiga.lib«. 

Um die Routinen nun auch bequem aufru- 
fen zu können, bieten sich diese Makros an: 

CALL . MACRO 


IFEQ 

NARG-2 


move.1 

\2,a6 

; A6 enthält noch nicht 
; den richtigen Wert 

ENDC 



IFLE 

NARG-2 


jsr 

_LV0\l(a6) 

ELSE 

FAIL CALL MACRO: PARAMETERFEHLER 

ENDC 



ENDM 




Die Benutzung des Makros ist einfach: 

CALL OpenLibrary 

falls A6 bereits _SysBase enthält, oder 
CALL OpenLibrary,_SysBase 

sofern A6 einen anderen Wert hat. Soll ein 
Aufruf am Ende einer Unterroutine stattfin¬ 
den, kann man das »jsr« durch ein »jmp« 
ersetzen und das neuen Makro »CALLRTS« 
taufen. Das hat allerdings den Nachteil, daß 
man beim Tracen im Debugger diese Routine 


dann durchlaufen muß; außerdem kann die 
Unterroutine dann keine Register restaurie¬ 
ren. 

Wichtig ist zudem eine vernünftige Form 
des Quelltextaufbaus. Die Unterroutinen soll¬ 
ten immer ausführlich kommentiert sein, so 
daß man auch nach längerer Zeit noch in der 
Lage ist, den Sinn und Zweck einer Unter¬ 
routine und ihre Arbeitsweise zu verstehen. 
Ein möglicher Header wäre: 
.**********************★**★***★******** 

; Finde ein Zeichen in einem String, der 
; nicht mit einem Nullbyte endet. 

; Ein: AO: Stringzeiger. 

; DO: Stringlänge. 

; Dl: zu findendes Zeichen. 

; Aus: DO: Position des gefundenen Zeichens. 

; -1, wenn nicht gefunden. 

Findezeichen 

rts 

Das ist natürlich nur ein Beispiel, zeigt 
aber sehr deutlich, welche Register die Rou¬ 
tine für die Parameterübergabe verwendet. 
Die Beschreibung ermöglicht es, die Routine 
zu verwenden, ohne ihre innere Arbeitsweise 
zu kennen. 

Richtige Makros 
erleichtern die 
Programmierung 

Wichtig ist dabei, daß verwendete Register 
am Anfang gerettet und nach Ende auch wie¬ 
der restauriert werden, um zerstörte Registe¬ 
rinhalte zu vermeiden. Das funktioniert z.B. 
mit dem MOVEM-Befehl: 

Findezeichen 

movem.l dl-d3/a0-al,-(SP) 

movem.l (SP)+,dl-d3/aO-al 
rts 

Es muß hierbei darauf geachtet werden, 
daß das Rückgaberegister DO nicht gerettet 
wird, denn dann bekäme man immer die 
Stringlänge als Ergebnis. Nun ist es unbe¬ 
quem und fehlerträchtig, wenn die Register¬ 
liste zweimal angegeben wird. Sind die 
Listen beim Retten und Restaurieren nämlich 
unterschiedlich, ist der Stack falsch, und der 
Rücksprung erfolgt in zufällige Bereiche. 
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NEU IDS ProKick 

externe Wdtstartumschaftung für A-500 / A-500 + 
ind. Eprombrenner und voNwertigen A-2000 Stets III 

- Blenden Sie Ihren internen Kick aus oder ein 

- Brennen Sie sich 2 Kicks nach Wahl in die Eproms 

- Nutzen Sie A-2000 Karten am A-500 

- Externes kleines Gehäuse für 2 A-2000 Slots 

- Interne Lösung mit 4 Slots für Towereinbau 

Weihnachtspreis: mit 512 KB Eproms DM 275.- 
mtti MB Eproms DM 299.- 



Versand: 

Frohnberg 23 

6921 Epfenbach 

Tel 07263/5693 Fax 1739 


Ausstellung 
Schatthäuserstr. 6 
6922 Meckesheim 
bei Heidelberg 
Tel 06226/60588 Fax 60688 


Distributor Schweiz 

PROMIGOS 

Hauptstr. 50 

CH-5212 Hausen 

Tel 056-32-21-32/34 Fax 41-15-82 


NEU IVS Vector 

Turbo-Board & SCSI Controller 

- 68EC030/25 MHz (in Kürze auch mit 33 oder 40 Mhz) 

- 68882/25 MHz Math Co-Processor 

- Trumpcard Professional "High-Speed"-SCSI-Controller 
-100% A2630 Expansion-Bus kompatibel 

- Erweiterbar bis 32 MB Ram mit SIMMS 

Weihnachtspreis: DM 1298.- 


I 


NEU IDS Tower 

Umrüstsatz für Ihren Amiga 500 / 500+ 

- Einfacher Einbau; alles vorgefertigt 

- incl. komplettem Kabelsatz 
-incl. 230 Watt Netzteil 

- incl. 2-farbigem Speeddisplay 

- Incl. 3.5" Drive mit normaler Frontblende 


Weihnachtspreis: DM 649.- 


NEU ROCTEC PiP View 


TV-Tuner + Picture in Picture Modul 

- Anschlüße für 3 Video- und 1 HF-Quelle 

- Infrarot Fernbedienung 

- 50 Programmspeicherplätze 

- Sie können z.B. in Ihr Amigabild ein Fernsehbild 

in ein kleines verschiebbares Window einblenden. 

- PiP beeinträchtigt in keiner Art die Leistung Ihres 
Amiga es ist eine externe Videolösung 


: DM 349. 


ALT 


3,5" Drive A-500 intern DM 119- 
3,5" Drive A-2000 intern DM 115.- 
3,5" Drive A-500 + extern DM 89- 
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